From a CA Gen modeling perspective, each Procedure Step that is packaged as part of a Server Manager has a set of properties. One of these properties identifies the PStep as being able to participate in a distributed transaction. If this property is set on a Procedure Step, the associated DPS is referred to as a Distributed Transaction Participant (DTP).
Note: The Distributed Transaction Participant check box on the Procedure Step Properties dialog is set in the model using either the Toolset or the CSE Construction Client.
The default value of a Procedure Step DTP property is off (not participating). Therefore, all types of cooperative flows (client-to-server or server-to-server) to the associated DPS result in a new transaction for each inbound request.
The target DPS participates in an existing distributed transaction when all of the following conditions are met:
If a transaction context does not exist (no client-to-server cooperative flow), a new transaction context is created prior to giving control to the target DPS.
The commit or rollback operation for a distributed transaction is coordinated across all participating DPSs and is deferred until each DPS involved in the same unit of work has completed.
For the clients created using CA Gen, the first DPS in a flow from the originating client always results in the creation of a new transaction. A new transaction is created regardless of whether the DPS has been defined as a DTP.
Java and .NET can support user-written clients that are able to participate in client initiated distributed transactions. In such cases, the user-written application is responsible for creating the transaction context that it extends to the first DPS invoked by the user-written client.
In the following illustration, none of the DPS applications extend an existing transaction by participating in a distributed transaction. Neither of the Procedure Steps associated with DPS 2 or DPS 3 are set as being a Distributed Transaction Participant. Therefore, flows to those DPSs results in the creation of a new transaction.
In the next illustration, DPS 2 is not a Distributed Transaction Participant (DTP). Therefore, a new transaction, Transaction 2, is created when DPS 1 flows to DPS 2. The flow from DPS 2 to DPS 3 occurs within the same transaction, Transaction 2. The synchronization of the work that is performed in DPS 2 and DPS 3 does not occur until DPS 2 returns to DPS 1. The work that is performed as part of Transaction 2 (DPS 2 and DPS 3) is committed independent to the work performed by Transaction 1 (DPS 1).
It is possible to extend a distributed transaction to more than one other DPS. The scope of the transaction continues as it includes other DPS applications as each of the participating DPS applications flows to other Distributed Transaction Participants. The following illustration shows three DPS applications participating in a single transaction.
An application may involve both stand-alone transactions and distributed transactions. Each transaction boundary represents its own unique sync-point. The following illustration shows two transactions. Transaction 1 is a distributed transaction, and Transaction 2 is a stand-alone transaction. The work that is done as part of DPS 3 is committed (or rolled back) as part of Transaction 2. The work that is done within the scope of Transaction 1 has its own transaction control and is committed (or rolled back) independent of how Transaction 2 completed.
This illustration has two transactions. Transaction 1 is composed of five DPS applications. Transaction 2 is composed of a stand-alone DPS application. The numbers in the circles identify the calling sequence.
|
Copyright © 2014 CA.
All rights reserved.
|
|