A taste from JAVA EE Transactions

Container-managed transactions examples in EJB 3.0

This post series will introduce some useful examples of how transactions (JTA) can be used efficiently  within a Java EE container. The correct usage of JTA transaction will be explained and some common pitfalls to avoid will be demonstrated. This post assumes that the reader has an understanding of what a transaction is, as well as what kind of problems transaction management can solve. This series is organized as follows: At first, an introduction to JTA transactions will be given in order to show how they can be enabled and used. 

Transaction Boundary

This part provides examples of how the scope of a JTA transaction (transaction boundary) can be influenced by using EJB’s transactional behavior attributes. 

In general, most EJB’s have one of the following three effects on the current transaction:

• commit the current transaction, 
• commit the current transaction and start a new transaction
• no effect on the current transaction

Single Transaction

The figure below illustrates a service that runs in a single thread and in a single transaction.

Figure 1: Service participating in the same transaction

The above figure illustrates the following:

• The TransactionManagementType annotation at the class level indicates that both session beans have Container Managed Transaction (CMT).
• The TransactionAttributeType annotation at the class level indicates that both session beans have the SUPPORTS value for all methods.
• The bean participates in a running transaction but does not require it.
• If there is no transaction, the method executes without a transaction.
• The TransactionAttributeType annotation at methodA and methodB methods in BeanA and BeanB respectively, overwrites the class level declaration and indicates that these specific methods have REQUIRED transaction value. This means:

• Methods must always execute in a transaction context.
• If there is a transaction already running, then the bean will participate in that transaction.
• If there is no transaction, the EJB container starts a transaction on behalf of the bean.
• The methodA of BeanA runs in a propagated transaction if present, otherwise in a new global transaction.
• The service invoked through BeanA (methodB of BeanB) participates in the global transaction and does not run in its own transaction.
• The changes that are made by the service invoked to the transactional resources are persisted when global transaction commits.
• If one of the operations within a transaction fails, then all of them are rolled-back so that the application is returned to its prior state.
• The transaction lasts only for a certain amount of time (the value can be set globally or per EJB).
• No transaction boundary is introduced as the transactional attributes defined in the EJBs allow the propagation of the global transaction across components.

Chained Transaction

The figure below illustrates a service that spans across two transactions.

Figure 2: Service spans in two transactions

The above figure illustrates the following:

• The TransactionManagementType annotation at the class level indicates that both session beans have CMT transaction.
• The TransactionAttributeType annotation at the class level indicates that both session beans have the SUPPORTS value for all methods. This means:
• The bean participates in a running transaction but does not require it.
• If there is no transaction, the method executes without a transaction.
• The TransactionAttributeType annotation at the methodA in BeanA, overwrites the class level declaration and indicates that this specific method has REQUIRED transaction value. This means:
• Methods must always execute in a transaction context.
• If there is a transaction already running, the bean participates in that transaction.
• If there is no transaction, the EJB container starts a transaction on behalf of the bean.
• The TransactionAttributeType annotation at the methodB in BeanB, overwrites the class level declaration and indicates that this specific method has REQUIRED_NEW transaction value.This means:
• A new transaction is always started when a method is called.
• If there is a transaction running, it is suspended.
• The container will start a new transaction and at the end of the method execution, it will commit or abort it.
• After that, the container will resume the client transaction.
• The methodA of BeanA runs in a propagated transaction if present, otherwise in a new global transaction.
• The service invoked through BeanA (methodB of BeanB) runs in its own new transaction and does not participate in the current BeanA transaction.
• Each transaction lasts only for a certain amount of time (the value can be set globally or per EJB).
• A transaction boundary is introduced as the transactional attributes defined in the EJBs does not allow the propagation of the global transaction across components.
• The changes that are made by the service invoked to the transactional resources are persisted when transaction of BeanB commits.
• If one of the operations within each transaction fails, then all of them are rolled-back so that the application is returned to its prior state.
• Potential duplicate messages may be introduced due to transaction timeouts (e.g. TXa ends before TXb commits)

References

[1] IBM Redbooks - Ueli Wahli, Giuseppe Bottura, Jacek Laskowski, Nidhi Singh - “WebSphere Application Server Version 6.1 Feature Pack for EJB 3.0." September 2008. Date of access: April 2013. http://www.redbooks.ibm.com/abstracts/sg247611.html

[2] Oracle Documentation - 6 authors - “The Java EE 5 Tutorial For Sun Java System Application Server 9.1.” June 2010. Date of access:May 2013. http://docs.oracle.com/javaee/5/tutorial/doc/bncij.html

[3] Oracle Documentation - "The Java EE 6 Tutorial" . January 2013. Date of access: June 2013. http://docs.oracle.com/javaee/6/tutorial/doc/bncih.html