The transaction attributes may be specified for a method on a bean that is declared as having container-managed transaction attributes for its methods
This attribute indicates that the business method must be invoked in the context of a transaction. If a transaction is associated with the caller, that transaction will be associated with the method invocation. If the caller does not have an associated transaction, the container will start a new transaction prior to invoking the business method on the bean instance, and will terminate the transaction when the business method has returned. This attribute guarantees that access to multiple transactional resource managers will be made in the context of a single global transaction�and helps to ensure that data consistencies are maintained across heterogeneous systems.
In this case, callers without a transaction context will receive a subclass of java.rmi.RemoteException, the Java Transactions API (JTA) exception javax.transaction.TransactionRequiredException. The container will not attempt to start a transactionon behalf of the caller. This is useful when failure of the business method must be correlated closely with the transactional integrity of resources associated with the caller�s transaction. A transaction attribute like Required cannot enforce this behavior. The Mandatory attribute could be used, for example, to ensure that fund transfers cannot happen independently of the success of a larger business operation in an e-commerce application.
This attribute indicates that the container should allow the invocation of the business method within the transaction context of a caller. However, the method may also be called with no transaction context associated with the caller. In that case the method will be invoked in an unspecified transaction context according to the semantics we explained for the NotSupported transaction attribute. The Supports transaction attribute allows the calling client to control the transactional characteristics of the business method. This can be a powerful construct for gaining operational efficiency from a business method used in different contexts. On the other hand, it means that required transactional behavior can be compromised by client misuse�and this can lead to data inconsistencies within an application.
Some people mistakenly believe that this attribute can be used to eliminate all interaction between the container and the transaction manager during a method invocation in which no transactional context is associated with the client.
Regardless of the container�s strategy for handling the unspecified transaction context, this is never the case; the container must still interact with the manager even in the simplest case. The efficiency is gained in the interaction with the database connections or Enterprise Integration System (EIS) adapters, which do not need to involve the XA transaction manager in their interactions
Or we might never have existed at all. Freaky. So we should cherish everything. Even this tiny ad: