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

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Ricky Ho
> Sent: Friday, February 14, 2003 7:41 AM
> To: Assaf Arkin; public-ws-chor@w3.org
> Subject: 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 ?

P2(T2) is completed after then end of the 2-phase commit. So if P1(T1) wants
to do something that occurs after the transaction it will have to wait for
the 2pc to complete before it can proceed.


> 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) ?

Yes, but that happens during rollback before the transaction completes. If
T2 is an atomic transaction then probably F2 will not be doing anything
useful since the entire transaction will rollback. For a non-atomic
transaction, F2 must do all the compensation work for what has happened
inside the transaction.


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

F2(T2) will compensate for what happened during T2 before T2 rolls back.
C2(T2) will compensate for what happened during the transaction after T2
commits. So F2 cannot execute C2.


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

If P1(T1) can complete without failure than the transaction will be
committed.

If an error occurs than a fault handler will be executed and if the fault
handler throws a fault then the transaction will abort, but at this point
the fault handler has already executed, so F1(T1) already took care of the
problem and the transaction will always rollback (in fact F1 marks T1 for
rollback only).

If no error occured during the transaction but the transaction cannot commit
for some reason (say communication failure, database integrity) then a fault
handler will be executed to do any clean up (if necessary). Since P1(T1)
completed all the work without failure, it assumes the transaction will
commit, but if it can't commit the fault handler can deal with that case.

From the perspective of the process there is no commit/rollback mechanism.
The process can only force the transaction to rollback while doing work in
the transaction, or react to the outcome by doing some fault handling if the
rollback is unexpected. The commit/rollback mechanism is invoked by the
engine when all work in the transaction has been done.


> >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

A child transaction must complete before the parent transaction has
completed, but a parent transaction cannot complete until all child
transactions have completed (where complete = commit or rollback).

I am looking at this from the perspective of structuring activities where
multiple concurrent activities can perform work in the same transactions
(e.g. in two different systems) and an activity can contain multiple child
activities in different transactions. Not from the perspective of
checkpoints where all checkpoints are automatically rolledback when the
parent transaction rollsback.

> 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).

From the perspective of one system you would not use transactions, you will
simply structure activities in such a way, so P1 contains the activities of
P2 and demarcates its execution, and P1 indeed calls C2 to compensate for
any work done by P2 after P2 completed.

From the perspective of multiple systems you have P2 in one system and P2'
in another system and P1 can't directly execute P2' or C2'. The transaction
provides a scope in which both P2 and P2' can execute, such that P2 and P2'
can complete with the same outcome and compensation for C2 and C2' can be
linked.


> >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.

In the case where P1 does T1 and P2 does T2 and P1 does P2 as part of its
work, then P1 initiates T1 and participates in T1, and P2 initiates T2 and
participates in T2, but also participates in T1 (i.e. if T1 aborts, so will
T2).

The case you are describing is more like P2 and P2' both doing work
concurrently in T2 (same transaction). Arbitrarily one is an initiator of
T2, but both are participants in T2.

arkin

>
> Best regards,
> Ricky

Received on Saturday, 15 February 2003 21:03:36 UTC