The following are some of the points to be remembered when specifying transaction attributes for Enterprise JavaBeans TM -technology based components (EJB TM ):
isIdentical()methods of the remote interface; and methods
getHomeHandle()of the home interface.
Requiredas the default transaction attribute, to ensure that methods are invoked within a Java Transaction API (JTA) transaction context.
Requiredcauses the enterprise bean to use existing transactional context if it exists, or to create one otherwise.
RequiresNewwhen 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
RequiresNewto add log entries.
RequiresNewalways 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.
Supportsfor 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.
Supportsuses the client transaction context if it exists, or no transaction context otherwise.
Mandatorywhen the method absolutely requires an existing transaction.
RemoteExceptionto be thrown unless the client is associated with a transaction context.
Neverto ensure that a transactional client does not access methods that are not capable of participating in the transaction.
RemoteExceptionto be thrown if the client is associated with a transactional context.
NotSupportedwhen 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
NotSupportedwill result in the method being called outside of any transaction context, whether or not one exists.
SessionSynchronizationmust have either the
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.
No, the J2EE platform supports only flat transactions.
javax.ejb.EJBContext.setRollbackOnly(), use the corresponding JTA API calls.
.commit(), and so on).
EJBContext, and then throwing an exception.
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.
No. Simply putting a transactional attribute on a method won't help if the resource manager can't use a transactional context.
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.