jQuery in Action, 3rd edition
The moose likes EJB and other Java EE Technologies and the fly likes Practical use of transaction attributes in EJBs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Practical use of transaction attributes in EJBs" Watch "Practical use of transaction attributes in EJBs" New topic

Practical use of transaction attributes in EJBs


Joined: May 24, 2005
Posts: 10
I am not sure about the use of these attributes:required,mandatory,supports etc.When would you deall each of them?Pls advise

Gopi Kishore

Joined: Sep 27, 2003
Posts: 15
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
I agree. Here's the link: http://aspose.com/file-tools
subject: Practical use of transaction attributes in EJBs
It's not a secret anymore!