Using Container-Managed JTA Transactions 

Use

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 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 that you must consider is the locking and the transaction isolation levels. For more information, see Locking.

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

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, SAP recommends the use of container-managed JTA transactions.

Prerequisites

·        You have not included transaction demarcation code in your component.

·        You have chosen Container transaction type in the component’s deployment descriptor (applicable to session and message-driven enterprise beans only; entity beans always use container-managed transaction demarcation). For more information, see Specifying Bean-Specific Properties.

Activities

Setting Transaction Attributes

For each business method of an enterprise bean, as well as for the methods defined in the home interface of an entity bean, you can set a transaction attribute in the bean’s deployment descriptor. The transaction attributes defines the transaction context, in which the EJB Container should invoke the method. For more information about the procedure, see Defining Transaction Attributes. If you do not set the transaction attributes explicitly, the EJB Container assigns the default transaction attribute – Supports for session beans and Required for entity beans.

Setting the transaction attributes is a very important step when you create a J2EE 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, which is 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:

Using Transaction Attributes

If you…,	Then…
Set up a message-driven beans	Use the Required or the NotSupported transaction attributes. Only these two attributes are allowed for message-driven beans in the EJB specification.
Develop a message-driven bean and want to 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.
Set up a CMP entity beans	Use the Required, the RequiresNew, or the Mandatory attribute. Although the EJB Container supports the use of the Supports, NotSupported, and Never attributes for CMP entity beans, you should avoid using them, because this feature is optional, and may make your enterprise bean unportable. Generally, you should be careful when using these attributes because the transactional behavior varies significantly according to the provided transaction context.
Implement javax.ejb.SessionSynchronization in your enterprise bean	You may 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.
Need to ensure 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 will not be ordered.
Need to ensure 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.
Do not need 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 may be changed concurrently by other clients. However, it does not guarantee data consistency during the method execution.

 

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. 

 

Setting the Transaction for Rollback

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

By invoking the setRollbackOnly()method of the javax.ejb.EJBContext method, you can tell the EJB Container to rollback the transaction. The invocation of this method is not allowed for beans with component-managed transaction demarcation.

Using Resources

To get 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, for each method that works with the data store you must implement the following operations:

       1.      Use the getConnection()method of the connection factory to obtain a connection handle.

       2.      Communicate with the data store using the connection.

       3.      Close the connection using its close() method. If you use a JDBC connection, also close the used statements before closing the connection.

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 J2EE Engine. This leads to resource leaks, which decrease performance, and might even cause server shutdown.

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