EJB – Transaction Management – Q’s and A’s

April 28, 2008 at 5:51 am (EJB, Technical Questions) (EJB, Q&A)

1.  Which transaction attributes should I use in which situations?

The following are some of the points to be remembered when specifying transaction attributes for Enterprise JavaBeans^TM-technology based components (EJB^TM):

• All methods of a session bean’s remote interface (and super interfaces) must have specified transaction attributes.
• Session bean home interface methods should not have transaction attributes.
• (All methods of an entity bean’s remote and home interfaces (and super interfaces) must have specified transaction attributes, with the exception of: methods getEJBHome(), getHandle(), getPrimaryKey(), isIdentical() methods of the remote interface; and methods getEJBMetaData(), getHomeHandle() of the home interface.
• Use Required as the default transaction attribute, to ensure that methods are invoked within a Java Transaction API (JTA) transaction context. Required causes the enterprise bean to use existing transactional context if it exists, or to create one otherwise.
• Use RequiresNew when the results of the method must be committed regardless whether the caller’s transaction succeeds. For example, a method that logs all attempted transactions, whether those transaction succeed or not, could use RequiresNew to add log entries. RequiresNew always creates a new transaction context before the method call, and commits or rolls back after the method call. Note that any existing client transaction context will be suspended until the method call returns.
• Use Supports for methods that either do not change the database (directly or indirectly); or update atomically, and it does not matter whether or not the update occurs within a transaction. Supports uses the client transaction context if it exists, or no transaction context otherwise.
• Use Mandatory when the method absolutely requires an existing transaction. Mandatory causes RemoteException to be thrown unless the client is associated with a transaction context.
• Use Never to ensure that a transactional client does not access methods that are not capable of participating in the transaction. Never causes RemoteException to be thrown if the client is associated with a transactional context.
• Use NotSupported when an enterprise bean accesses a resource manager that either does not support external transaction coordination, or is not supported by the J2EE product. In this case, the bean must have container-managed transaction demarcation, and all its methods must be marked NotSupported. NotSupported will result in the method being called outside of any transaction context, whether or not one exists.
• Enterprise beans that implement interface SessionSynchronization must have either the Required, RequiresNew, or Mandatory transaction attribute.

2.  How can I handle transaction isolation?

The EJB specification indicates that the API for controlling transaction isolation level is specific to the resource manager implementation, and therefore the architecture does not define and isolation level control API.

If a container uses only one bean instance per primary key, the container will synchronize access to the bean and therefore transaction isolation is unnecessary. Containers that use multiple instances per primary key depend on the underlying database for isolation.

Enterprise beans using container-managed persistence use the default isolation level of the underlying database; therefore, the isolation level cannot modified. Entity beans using bean-managed persistence may use the underlying DBMS API to change the isolation level (using, for example, Connection.setTransactionIsolation().)

3.  Does the J2EE platform support distributed transactions?

Yes, the J2EE platform allows multiple databases to participate in a transaction. These databases may be spread across multiple machines, using multiple EJB technology-enabled servers from multiple vendors.

4.  Does the J2EE platform support nested transactions?

No, the J2EE platform supports only flat transactions.

5.  What are some tips for using bean-managed transaction demarcation?

• Session beans should use bean-managed transaction demarcation, although can use container-managed demarcation. Entity beans must use container-managed demarcation.
• An enterprise bean should not invoke resource manager-specific transition demarcation API methods (like java.sql.Connection.commit(), java.sql.Connection.rollback(), etc.) while within a transaction.
• Stateless session beans should always either commit or rollback a transaction before the business method returns. Stateful session beans do not have this requirement. Instead of calling EJBContext.getRollBackOnly(), and javax.ejb.EJBContext.setRollbackOnly(), use the corresponding JTA API calls.

6.  What are some tips for using container-managed transaction demarcation?

• Do not invoke a resource-manager-specific transaction demarcation API (like Connection.commit(), and so on).
• Avoid using interface UserTransaction.
• Implement rollbacks by calling EJBContext, and then throwing an exception.

7.  Can an entity bean use bean-managed transaction demarcation?

No. Entity beans always use container-managed transaction demarcation. Session beans can use either container-managed or bean-managed transaction demarcation, but not at the same time.

8.  Should I put a transactional attribute on an asynchronous action such as sending an email?

No. Simply putting a transactional attribute on a method won’t help if the resource manager can’t use a transactional context.

9.  Can I use multiple connections to the same resource manager from within a bean instance that executes in an XA or a global transaction ?

A bean instance that executes in an XA or a global transaction should not use multiple connections to the same resource manager.

Specifically, a bean instance that executes in an XA transaction should not cache more than one connection to the same resource manager. Further, it should not create more than one connection to the same resource manager from within a bean method under a single XA transaction.

This is needed because even though XA allows multiple connections to be enlisted in a single transaction branch, there are some restrictions. Some resource managers do not allow more than one connection to be simultaneously enlisted in the same transaction branch.

Note however that within a single XA transaction, there can be more than one connection to a single resource manager, spread across different bean instances.