Re: Some comments on definition of operation/group and action

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 ()
Transactions Architect, HP 
Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203