Two points I tried to make here 1) if once an operation
commits/completes its data is accessible to other operations and transactions
thus a backward recovery might not be possible - we cannot guarantee that. In
order to guarantee a reversible operation one definitely needs more rigorous
rules and mechanisms to prevent any operation to violate that (the
constraint). We need an entity, something like a gatekeeper of the group
operations and groups defined consistency constrains. 2) Sine a backward
recovery (thru compensation) is not always possible one may try forward
recovery (thru some compensation and some contingency operations) which makes
the group like action defined in the requirements doc. I belive at action
level we have both forward and backward
operations. >>>>
I'd like to see us considering the use of nested transactions for
groups.
Why applications responsibility? There should be some ways to do some
level of check thru some entities that are part of BTP. For example if the
structure of transactions known one may check transactional dependencies
between transactions to prevent conflicting operations, specially if they are
ACID transactions. Letting these checks build/designed by application will
surely create applications where cascading rollbacks and compensations are
common and creating a lot of problems. >>>>
In a loosely coupled environment like the Web this is going to be an almost
intractable problem. It's similar in problem to distributed deadlock-detection,
and that's still an open area of research work! For a start you'd require that
the entities used within a transaction are known before you begin, which is
certainly not always going to be the case.
Mark.
---------------------------------------------- Dr. Mark Little ( mark@arjuna.com) Transactions Architect, HP
Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203
|