18.2.3. WS_Transaction Models
22.214.171.124. Atomic Transactions
Procedure 18.1. Atomic Transaction Process
- To begin an atomic transaction, the client application first locates a WS-C Activation Coordinator web service that supports WS-Transaction.
- The client sends a WS-C
CreateCoordinationContextmessage to the service, specifying http://schemas.xmlsoap.org/ws/2004/10/wsat as its coordination type.
- The client receives an appropriate WS-Transaction context from the activation service.
- The response to the
CreateCoordinationContextmessage, the transaction context, has its
CoordinationTypeelement set to the WS-Atomic Transaction namespace, http://schemas.xmlsoap.org/ws/2004/10/wsat. It also contains a reference to the atomic transaction coordinator endpoint, the WS-C Registration Service, where participants can be enlisted.
- The client normally proceeds to invoke Web Services and complete the transaction, either committing all the changes made by the web services, or rolling them back. In order to be able to drive this completion activity, the client must register itself as a participant for the
Completionprotocol, by sending a
Registermessage to the Registration Service whose endpoint was returned in the Coordination Context.
- Once registered for Completion, the client application then interacts with Web Services to accomplish its business-level work. With each invocation of a business Web service, the client inserts the transaction context into a SOAP header block, such that each invocation is implicitly scoped by the transaction. The toolkits that support WS-Atomic Transaction-aware Web Services provide facilities to correlate contexts found in SOAP header blocks with back-end operations. This ensures that modifications made by the Web service are done within the scope of the same transaction as the client and subject to commit or rollback by the transaction coordinator.
- Once all the necessary application-level work is complete, the client can terminate the transaction, with the intent of making any changes to the service state permanent. The completion participant instructs the coordinator to try to commit or roll back the transaction. When the commit or roll-back operation completes, a status is returned to the participant to indicate the outcome of the transaction.
- The first of these protocols is the optional Volatile2PC (2PC is an abbreviation referring to the two-phase commit). The Volatile2PC protocol is the WS-Atomic Transaction equivalent of the synchronization protocol discussed earlier. It is typically executed where a Web service needs to flush volatile (cached) state, which may be used to improve performance of an application, to a database prior to the transaction committing. Once flushed, the data is controlled by a two-phase aware participant.When the completion participant initiates a
commitoperation, all Volatile2PC participants are informed that the transaction is about to complete, via the
preparemessage. The participants can respond with one of three messages:
readonly. A failure at this stage causes the transaction to roll back.
- The next protocol in the WS-Atomic Transaction is Durable2PC. The Durable2PC protocol is at the core of WS-Atomic Transaction. It brings about the necessary consensus between participants in a transaction, so the transaction can safely be terminated.The Durable2PC protocol ensures atomicity between participants, and is based on the classic technique of two-phase commit with presumed abort.
Procedure 18.2. Durable2PC Procedure
- During the first phase, when the coordinator sends the prepare message, a participant must make durable any state changes that occurred during the scope of the transaction, so these changes can either be rolled back or committed later. None of the original state information can be lost at this point, since the atomic transaction may still roll back. If the participant cannot
prepare, it must inform the coordinator, by means of the
abortedmessage. The transaction will ultimately roll back. If the participant is responsible for a service that did not change any of the transaction's data,, it can return the
readonlymessage, causing it to be omitted from the second phase of the commit protocol. Otherwise, the
preparedmessage is sent by the participant.
- If no failures occur during the first phase, Durable2PC proceeds to the second phase, in which the coordinator sends the
commitmessage to participants. Participants then make permanent the tentative work done by their associated services, and send a
committedmessage to the coordinator. If any failures occur, the coordinator sends the
rollbackmessage to all participants, causing them to discard tentative work done by their associated services, and delete any state information saved to persistent storage at
prepare, if they have reached that stage. Participants respond to a rollback by sending an
abortedmessage to the coordinator.
NoteThe semantics of the WS-Atomic Transaction protocol do not include the one-phase commit optimization. A full two-phase commit is always used, even where only a single participant is enlisted.
Figure 18.6. WS-Atomic Two-Phase Participant State Transitions
Completionprotocol that originally began the termination of the transaction can complete, and inform the client application whether the transaction was committed or rolled back. Additionally, the Volatile2PC protocol may complete.
preparephase of Volatile2PC, the final phase is optional and can be used to inform participants about the transaction's completion, so that they can release resources such as database connections.
Figure 18.7. AT protocol model