RE: Behavior of compensating transaction under "initiator" and "participant" role

Assaf, Thanks for your feedback !  My question embedded ...

Lets say process P1 start a transaction T1 and invoke process P2 which 
start a transaction T2.  (In other words, T1 is the parent transaction of 
T2).  Lets also assume P1 and P2 are running in a different machine and 
also there is a transaction co-ordinator running in yet another different 
machine.  There is also a co-ordination framework running along with the P1 
/ P2 who deals with the 2-phase commit handshaking protocol.

P1(T) is the process flow definition of P1
F1(T) is the fault handler of P1
C1(T) is the compensation flow of P1

Similarly P2(T), F2(T), C2(T) is defined in a similar way.

At 07:39 PM 2/13/2003 -0800, Assaf Arkin wrote:
>If the transaction has not completed yet, then the transaction will
>rollback. It may be as simple as rolling back all the changes, or require
>some activities to execute (e.g. from a fault handler).

Lets say every line of P2(T2) is done.

If T1 is the parent transaction of T2, then P2 must be waiting for the 
transaction-coordinator to trigger a 2-phase commit protocol.  Do you 
considered P2(T2) is completed or NOT ?

Are you saying that F2(T2) will be invoked automatically by the 
co-ordination framework at P2 if the transaction coordinator decide to 
rollback the transaction (for whatever reason) ?

And then it is up to F2(T2) to determine what to do.  It may or may not 
execute C2(T2) ?

In such case, will F1(T1) be also automatically invoked ?  even if it is 
P1(T1)'s decision to rollback the transaction ?


>If the transaction has completed then it cannot rollback. However, a parent
>transaction may want to undo the effects of a child transaction that has
>completed. The parent transaction then 'compensates' for the child
>transaction.

I don't understand how a child transaction can completed before a parent 
transaction.  Are you talking "parent/child" from an invocation perspective 
but not from a transaction perspective ?  In this case, you are referring 
to T2 is a separate transaction of T1 because T2 is considered "completed" 
when every line of P2(T2) is done.  In other words, T2 bares no relation 
with T1 from a transaction perspective.  But because P1 is a parent of P2 
from an invocation perspective, so P1(T1) will invoke C2(T2) to fix the 
problem itself.  The co-ordination framework at P2 won't be involved and 
won't automatically trigger C2(T2).


>It does not matter whether a particular process initiated the transaction
>since all processes are participants and rollback/compensation applies to
>all participants without prejudice.

I don't understand this.  I guess P1 is considered as an "initiator" but 
NOT a "participant".  P2 is considered as a "participant".  And their 
behavior are quite different ...
1) Beginning of P1 create a transaction; Beginning of P2 enroll under an 
existing transaction
2) End of P1 ask the transaction coordinator to start a 2PC 
handshaking.  End of P2 sit there and wait for the transaction coordinator
3) P1 logic decide to rollback the transaction, it is NOt consider a fault 
from P1 side.  But P2 consider this as a fault.

Best regards,
Ricky

Received on Friday, 14 February 2003 10:41:34 UTC