The following illustration shows the effect of defining Server PSteps as Distributed Transaction Participants (DTP) for three different distributed flows.
Note: Since PStep1 is the first server PStep in each flow, it always results in the creation of a new transaction. PStep1 is always defined as transactional regardless of whether Distributed Transaction Participant is set or not. The originating client is always outside the scope of transactional awareness.
Flow A-Shows the condition where PStep2 and PStep3 are individually detailed as Distributed Transaction Participants. The Distributed Transaction Participant check box is on.
Flow B-Shows the condition where PStep2 was detailed as not a Distributed Transaction Participant (default behavior). PStep2 breaks the flow into two transactions and creates a new transaction with PStep3 that has Distributed Transaction Participant set.
Flow C-Shows the condition where PStep2 and PStep3 are not set as Distributed Transaction Participants. In this case, the flow is separated into three transactions.
The commit or rollback operation for a Distributed Transaction is coordinated across all participating Procedure Steps. It is deferred until all the Procedure Steps participating in the transaction have completed.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|