- From: Ricky Ho <riho@cisco.com>
- Date: Fri, 14 Feb 2003 07:40:56 -0800
- To: "Assaf Arkin" <arkin@intalio.com>, <public-ws-chor@w3.org>
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