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

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

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.

In term of modularity, in some cases the compensation logic is dependent on
the transaction logic (e.g. using the same context to determine what actions
need to take place). You would want to define the compensation logic
alongside the transaction logic and invoke that logic from the parent
transaction (and not just when it rollsback).

In other words (in process terms) if P(T) is a process that performs some
transaction and C(T) is a process that compensates form that transaction,
then C(T) is written as part of P(T) but C(t) can only be invoked after P(t)
completed and only if P(t) has completed and succesffuly only once.

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.

arkin


> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Ricky Ho
> Sent: Thursday, February 06, 2003 10:15 PM
> To: public-ws-chor@w3.org
> Subject: Behavior of compensating transaction under "initiator" and
> "participant" role
>
>
>
> A question about how "orchestration" and "co-ordination" work together.
>
> Within a BPEL/BPML process, you can put a transaction scope
> around a block
> of activities, and also attach another block of activities called
> "compensating transaction", which is supposed to undo the
> "transaction".  I
> would like to compare the behavior of this process when it is playing the
> "transaction initiator" role vs the "transaction participant" role.
>
> If this process is the "TRANSACTION INITIATOR" (ie: the top-level
> transaction), then when this block is entered, the orchestration engine
> will make a call to the transaction co-ordinator to create a new
> transaction and obtain a transaction id.  For every <invoke> within the
> block, the transaction id will be embedded in the SOAP header.  Also, the
> "compensating transaction" will never be invoked automatically by the
> orchestration engine.  It can only be invoke "explicitly" by another
> application-level flow (e.g. by the exception handling flow logic).
>
> However, if this process is the "TRANSACTION PARTICIPANT" (ie: being
> invoked by another application which already have a transaction context),
> then when this block is entered, the orchestration engine will
> make a call
> to the transaction co-ordinator to enroll itself as a participant of the
> outer transaction.  Lets say after some time the transaction coordinator
> start the 2-phase commit handshaking protocol.  When the transaction
> co-ordinator ask for "prepare", the orchestration engine will simply
> respond a "prepared" without doing anything.  When the transaction
> co-ordinator ask for "commit", the orchestration engine will just
> respond a
> "commited", again without doing anything.  However, when the transaction
> co-ordinator ask for "cancel", the orchestration will execute the
> "compensating transaction" and then respond a "cancelled".  One key
> difference is now the "compensating transaction" will be automatically
> invoked by the orchestration engine as part of the 2 phase commit
> handshaking.  The compensating transaction shouldn't be invoked by the
> application flow explicitly.
>
> Is this a correct understanding of how orchestration and
> co-ordination work
> together ?
>
> On the other hand, can a BPEL process participating in an outer
> transaction
> specify a block of activities for "prepare", another block for "commit",
> another one for "cancel" ?
>
> Thanks in advance,
>
> Best regards,
>
> Ricky

Received on Thursday, 13 February 2003 22:41:19 UTC