XA transaction processing

To illustrate the importance of the X/open XA interface in JTA transaction management, and the timing of its use, the EJB code for a fixed income transaction mentioned in the previous chapter is an example:

 @TransactionAttribute (transactionattributetype.required)   public void  Placefixedincometrade (Tradedata trade)  throws Exception {       try {          ...           placement placement =  placementservice.placetrade (trade);          executionservice.executetrade (placement);       } catch  (tradeexecutionexception e)  {           log.fatal (e);           Sessionctx.setrollbackonly ();          throw e;       }  } 

 @TransactionAttribute (transactionattributetype.required) Public void placefixedincometrade ( Tradedata trade)  throws Exception {     try {          ...         placement  placement =  placementservice.placetrade (trade);          placementservice.sendplacementmessage (placement);          executionservice.executetrade (placement);     } catch  ( Tradeexecutionexception e)  {         log.fatal (e);          sessionctx.setrollbackonly ();          throw e;    } } 

Although the above modifications are simple enough, this code does not guarantee the acid guidelines. If the Executetrade () method throws a tradeexecutionexception, the database change will be rolled back, but the transaction-preset message will be sent to the JMS queue or topic. In fact, the transaction preset message is likely to be released (consumed) by the queue or topic after the Sendplacementmessage () method has been executed.

Because in a non-XA environment, the insertion process of Message Queuing is independent of the database update operation, the atomicity and independence in the acid guidelines are not guaranteed and thus the overall data integrity is compromised. What we need is a way to keep message queues and databases under the control of a single transaction, so that two resources can be coordinated to form a single unit of work. With the X/open XA interface, we are able to coordinate multiple resources to ensure the maintenance of the acid guidelines.

Xa interface detailed

The X/open XA interface is a two-way system interface that forms a communication bridge between the transaction manager (Transaction Manager) and one or more resource managers (Resource Manager). The transaction manager controls JTA transactions, manages the transaction life cycle, and coordinates resources. In JTA, the transaction manager is abstracted as an Javax.transaction.TransactionManager interface and implemented through the underlying transaction service (that is, JTS). The resource manager is responsible for controlling and managing actual resources, such as databases or JMS queues. Describes the relationship between the transaction manager, the resource manager, and the client application in a typical JTA environment:

Note that the medium XA interface forms the communication bridge between the transaction manager and the resource manager. Because of the bidirectional nature of the XA interface, XA supports the two-phase commit protocol, which we will discuss later in this chapter.

The content described in this chapter is difficult to cover all the details of the XA interface. If the reader cares about XA details, refer to the X/open XA interface specification (available in PDF format in http://www.opengroup.org/onlinepubs/009680699/toc.pdf).

When should I use XA?

In Java transaction management, a frequently confusing question is when to use XA and when not to use XA. Because most commercial application servers perform single-phase commit (One-phase commit) operations, performance degradation is not an issue worth considering. However, the non-necessity of introducing XA database drivers into your application can lead to unpredictable consequences and errors, especially when using the local transaction model (Transaction models). Therefore, it is generally necessary to avoid using XA when you do not need it. The following best practices describe when XA should be used:

The most common scenario for requiring and using XA is to reconcile database changes and message queues (or topics) in the same transaction. Note that these two operations may occur in completely different places (especially when using an ORM framework like hibernate). An XA transaction must reconcile two types of resources when a rollback event occurs, or leave the changes isolated from other transactions. If there is no XA, messages sent to the queue or subject will even arrive and be read before the transaction terminates. In an XA environment, messages in the queue are not freed until the transaction commits. In addition, if you are coordinating an operational database and a read-only database (that is, the reference database), you do not need XA. However, because XA supports read-only optimization, you may not see any performance penalty when a read-only data source is introduced into the XA transaction.

When you intend to use XA in your enterprise Java applications, there are a few hidden issues that need to be considered. These issues include two-phase commit (2pc,two-phase commit process), experience anomalies, and the use of XA drivers. The following chapters describe these issues separately.

Two-phase commit

When a commit () request is issued from the client to the transaction manager, the transaction manager begins the two-phase commit process. In the first phase, all the resources are polled and asked if they are ready to submit the job. Each participant may answer "ready", "read-only (READ_ONLY)", or "not Ready (Not_ready)". If any of the participants responds with "Not Ready (Not_ready)" In the first stage, the entire transaction is rolled back. If all participants answer "ready", then these resources are submitted in the second phase. The answer to "read-only (READ_ONLY)" Resources is excluded from the second-phase processing of the protocol.

Two-phase commit becomes possible due to the ability of bidirectional communication in an XA environment. In a non-XA transactional environment, communication is only one-way, and two-phase commits cannot be done because the transaction manager is unable to receive a response from the resource manager. Most transaction managers, in order to optimize performance, release resources as quickly as possible, using multithreading to handle the first phase of polling and the second phase of the commit process. Shows the basic process for two-phase commits:

XA transaction processing