XA (eXtended Architecture)
XA stands for “eXtended Architecture” and is an X/Open group standard for executing a “global transaction” that accesses more than one back-end data-store. XA specifies governs how a transaction manager will roll up the transactions against the different data-stores into an “atomic” transaction and execute this with the two-phase commit (2PC) protocol for the transaction.
Two-phase commit requires a common interface between the transaction managers and the participating resources. This is achieved using the common standard “XA”. It is a specification from X/Open group.
For a commit process to work in XA, following steps are performed by the transaction manager on each of the participating resources:
- Instruct the resource to join the transaction – start(Xid)
- If no more transaction related work to be done by this resource, instruct it to end it – end(Xid)
- Transaction managers asks the resource if it is ready to commit the transaction – prepare(Xid)
- Now transaction manager instructs the resource to commit the transaction – commit(Xid)
Xid is the transaction id for a participating resource. It contains “global transaction id” which is same for all participating resources and a “branch qualifier” which the participating resource needs to take care of.
For XA to work correctly it requires two very important things which should be taken care of. They are:
- The transaction manager should be XA-aware (XA understanding)
- All the resources participating should be XA-aware
The first one can be provided by Java Transaction API’s transaction managers and the second one needs to be provided by the resource vendors. Mind you, JTA can also be used without XA but for XA to work you definitely require JTA.
Java Transaction API (JTA) is allows your transaction manager to communicate with your application server, the application program, and the resource managers, using a well-defined and standard API. It specifies how external resources communicate with the transaction manager. The JTA defines a set of high-level interfaces that describe the contract between the transaction manager and three application components that interact with it: the application program, resource manager, and application server. Since JTA provides interfaces that map to X/Open standards, a JTA-compliant transaction manager can control and coordinate a transaction that spans multiple resource managers, yes distributed transactions.
There is another specification that deals with the implementation details of transaction managers, called Java Transaction Service (JTS). JTS specification also mandates that a JTS-compliant transaction manager implement all JTA interfaces—that is, a JTS-based transaction manager interfaces with an application program, the application server, and resource managers, using the JTA.
The JTA primarily consists of three parts as summarized below:
- A high-level application interface namely “UserTransaction” which can be used by an application to demarcate its transaction boundaries.
- A corresponding Java mapping of the industry standard X/Open XA protocol. This core interfaces for this are defined in the javax.transaction.xa package and they are XAResource, Xid and XAException interfaces.
- A high-level transaction manager interface which allows an application server to manage transactions for a user application. The various interfaces namely TransactionManager, Transaction, Status and Synchronization define how the application server manages your applications transactions.
JTA support is built-in with JEE/JEE servers, but there exists standalone implementations as well in the market which doesn’t require bulky application servers to get the advantages provided by JTA transaction manager. Some of the well known standalone implementations are:
- JOTM (Java Open Transaction Manager)
How does Spring work with JTA? Spring gives you very good support for using JTA in your application. Spring provides the necessary plumbing for running an application with any JTA implementation following its core principle of integration. This also makes it unique in the sense that an application doesn’t need to run in a JEE container to get the benefits of JTA transactions. It is important to not here that Spring by itself doesn’t have a JTA implementation of its own, rather it allows your application to integrate with any JTA implementation by mere configurations.
Spring provides both programmatic and declarative transaction management using a lightweight transaction framework making it easy for standalone java applications to include transactions (JTA or non-JTA) either programmatically or declaratively. The programmatic transaction demarcation can be accomplished by using the API exposed by the PlatformTransactionManager interface and its sub-classes and the declarative transaction uses the concept of AOP.
The class org.springframework.transaction.jta.JtaTransactionManager class is part of the Spring’s transaction management support. This class is an implementation of PlatformTransactionManager interface which delegates to a backend JTA provider. This is typically used to delegate to a Java EE server’s transaction coordinator, but may also be configured with a local JTA provider which is embedded within the application. For a single JDBC DataSource, DataSourceTransactionManager is perfectly sufficient, and for accessing a single resource with Hibernate, HibernateTransactionManager is appropriate.
Configuring transaction amanger in your Spring application is as easy as declaring it in your Spring configuration file. If you are within a JEE server, you can just as Spring to lookup the JTA transaction manager by specifying the following as shown in Listing 18-27 below.
Listing 18-27. Lookup JTA transaction manager of Application server
Note: Transaction relation configurations can be done easily and in simple way using the “tx” namespace. We will cover Spring namespaces in Chapter 25.
In the case of stand-alone applications, declaring the transaction manager as a bean in your Spring configuration file is as shown in Listing 18-28 below. All the relevant resources required for the transaction manager can be either declared or it can looked up from JNDI as appropriate for your application. Here the property “transactionManager” can be any of the standalone JTA implementation as discussed earlier.
Listing 18-28. Declaring transaction manager as Spring bean
<bean id=”transactionManager” class=”org.springframework.tx.jta.JtaTransactionManager”>
<property name=”transactionManager” ref=””/>
<property name=”userTransaction” ref=””/>
In Listing 18-29, configuring transaction manager using stand-alone transaction manager Atomikos is shown.
Listing 18-29. Declaring transaction manager whch uses Atomikos
<property name="forceShutdown" value=”true”/>
<bean id="atomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp"/>
<property name="transactionManager" ref=”atomikosTransactionManager”/>
<property name="userTransaction" ref=”atomikosUserTransaction”/>
Note: Its good to name your transaction manager bean as “transactionManager” so that other Spring components can find the transaction manager by its own rather than you wiring it up for them.
Transaction demarcation as the word suggests indicates where your transaction should start and end. In Spring demarcation of transaction is done declaratively either by using @Transactional annotation or by appropriate Spring AOP pointcuts. Spring’s advantage in this area is that to handle global transactions it is not required to do any code changes as it can be done purely declaratively using Spring AOP.
The various transaction requirements and its demarcation can be grouped and summarized as following:
- Local Transactions – use acknowledge=”transacted” when defining appropriate beans
- Distributed transactions with synchronous message handling – use @Transactional annotation along with <tx:annotation-driven/> (for scanning transaction related annotation) or you can use Spring AOP and define <tx:advice/> according to application requirement.
- Distributed transactions with asynchronous message handling – pass on the JTA transaction manager to the message listener container as shown in Listing 18-30 below.
Listing 18-30. Passing on transaction manager to the message listener container
<jms:listener ref=”jmsListener” destination=”myQueue”/>
The Chapter stared with messaging basics and delved deep into its advantages. The main benefits of messaging are; flexibility, scaling, resilience and better performance. There are better and well established mature solutions available in the industry supporting messaging capabilities which can be used in your application.
We then covered the message system types in detail. Later on we looked at JMS and delved deep into it in much detail. Then we covered Spring in context of JMS. Later on we covered JTA and the support given by Spring in combining JTA in your Spring application.
Spring framework can be integrated with JTA implementations to provide distributed transactions and how it could cater to the needs of an application which required distributed transactions without the need for a full-blown JEE server.
After reading this Chapter you should now have a clear idea of messaging in general and the support provided by Spring in creating application which are message-oriented in nature. You should now be able to use Spring’s JmsTemplate and message listener containers in your application. Also you should now be able to use the JTA transaction manager to manage transactions in your Spring application.
Page Visitors: 13166
Latest posts by Tomcy John (see all)
- Best way to persuade/communicate – Pyramid Principle - December 3, 2017
- Checklist when you are reviewing a product – technically and architecturally - November 30, 2017