Using Container-Managed JTA Transactions

Container-managed transaction demarcation is the easiest approach for dealing with transactions from the application viewpoint — you do not have to write anything related to transactions in your application code. The EJB Container is responsible for initiating and completing the transaction. In addition, it deals with synchronization matters, ensures data consistency, and so on.

However, you also have the responsibility for defining the transactional behavior of the application components, and particularly, of the enterprise beans that you deploy — you do this by specifying transaction attributes for the beans' business methods.

Another issue, which you must consider, is the locking and the transaction isolation levels.

Additionally, you must take care of the way you use resources — that is, opening and closing connections to the underlying data store.

Recommendation

Using container-managed transactions after carefully defining the transaction attributes and the use of resources simplifies development and ensures the correct functioning of your application component. Therefore, we recommend that you use container-managed JTA transactions.

End of the recommendation.

Prerequisites

You have not included transaction demarcation code in your component.
You have selected Container transaction type for your session and message-driven bean.

Procedure

Setting Transaction Attributes

For each business method of an enterprise bean, you can set a transaction attribute in the bean's deployment descriptor. The transaction attribute defines the transaction context, in which the EJB Container should invoke the method.

More information: Specifying Transaction Attributes

If you do not set the transaction attributes explicitly, the EJB Container assigns the default transaction attribute Supports for session beans.

Setting the transaction attributes is an important step when you create a Java EE application with enterprise beans. It enables you to define the transactional behavior of your component declaratively, without dealing with its code. The correct and efficient functioning of the enterprise bean later depends on what transaction attributes you have set for its methods.

The EJB specification defines the following transaction attributes:

Required
If the client call comes with a transaction context, the EJB Container invokes the business method in this context; otherwise, the container starts a transaction and invokes the method within it.
RequiresNew
The EJB Container suspends any running client transaction, and starts a new transaction, within which it executes the business method. After the method returns, the container resumes the suspended transaction.
Mandatory
This attribute requires a running transaction, that is, the EJB Container may invoke the business method only if a transaction context already exists. If there is no transaction context, the container throws an exception; otherwise, it processes the call as in the Required scenario.
Supports
If a transaction context already exists, the EJB Container acts as in the case with the Required attribute. If there is no transaction context, the container acts as in the NotSupported scenario (described below).
NotSupported
If the client call comes with a transaction context, the EJB Container suspends the context and invokes the method outside the transaction.
Never
The EJB Container may invoke a method with this transaction attribute only outside a transaction. If the client call is without a transaction context, the container acts as in the NotSupported scenario; otherwise, it throws an exception to indicate an error.

Guidelines for Using Transaction Attributes
Task	Steps
Setting up a message-driven bean	Use the `Required` or the `NotSupported` transaction attributes. Only these two attributes are allowed for message-driven beans in the EJB specification.
Developing a message-driven bean and specifying the invocation of the `onMessage()` method upon message receipt to be a part of a transaction	Use the container-managed transaction approach and set the transaction attribute of the `onMessage()` method to `Required`.
Implementing `javax.ejb.SessionSynchronization` in your enterprise bean	You can use the `Required`, `RequiresNew`, or `Mandatory` attributes only. This ensures that the bean's methods are invoked in a transaction, which enables the EJB Container to send transaction synchronization calls.
Ensuring that a sequence of methods is called in a single transaction	Use the `Required` attribute. For example, if bean A withdraws money from a bank account, which is used for buying a commodity ordered by bean B, the invocations of the relevant methods of the beans should be in a single transaction. Thus, if the money is not available or cannot be withdrawn for certain reason, the commodity is not ordered.
Ensuring that the bean's method runs in a new transaction	Use the `RequiresNew` attribute. It is typically used in a scenario when you need to separate the business logic implemented in a particular method from the work done by the other methods.
Bypassing the transactional access to the database, that is, you do not need to keep the data in the database unmodified by concurrent operations during the method execution	Use the `NotSupported` attribute. It saves overtime because the data that the bean accesses is not locked in the database, and it can be changed concurrently by other clients. However, it does not guarantee data consistency during the method execution.

Recommendation

If you are uncertain which transaction attribute to choose, use the Required attribute to ensure the method is invoked within a transaction, or the NotSupported attribute to ensure the method is called outside a transaction.

End of the recommendation.

Setting the Transaction for Rollback

In addition to defining the transactional behavior of the bean by setting the transaction attributes, you can also influence the result of a container-managed transaction.

You can set the EJB Container to roll back the transaction by invoking the setRollbackOnly() method of the javax.ejb.EJBContext interface. The invocation of this method is not allowed for beans with component-managed transaction demarcation.

Using Resources

To obtain a connection to the underlying data store, you must first look up the relevant connection factory from the naming system. This might be a DataSource, a PersistenceManagerFactory, or an instance of javax.resource.cci.ConnectionFactory. This is typically done at an early stage of the component's life cycle, for example, in the setEJBContext() method of an enterprise bean, or in the init() method of a servlet.

To ensure optimal use of resources when using container-managed transactions, you must implement the following operations for each method that works with the data store:

Use the getConnection() method of the connection factory to obtain a connection handle.
Communicate with the data store, using the connection.
Close the connection, using its close() method. If you use a JDBC connection, also close the used statements before closing the connection.

Note
Do not forget to close the connection handle eventually. If the handle remains open, the associated physical connection cannot be returned to the connection pool maintained by the AS Java. This leads to resource leaks, which decrease performance, and might even cause server shutdown.

End of the note.

Recommendation

Leaving the prepared statements open can lead to their state being inconsistent when they are reassociated to the next connection handle that you get. Therefore, we recommend that you close the statements before closing the connection.

End of the recommendation.