EJBs and Container-Managed Transactions





EJBs and Container-Managed Transactions

So how do we get around the limitations of JTA with EJBs? First you need to review the three ways of controlling transactions defined in the EJB specification:

  • Client demarcation— The programmer of a client uses the explicit programmatic transaction management of JTA. The methods of the interface javax.jts.UserTransaction are used to begin, commit, or roll back the transaction.

  • Bean demarcation— A session EJB with the transaction attribute set to TX_BEAN_MANAGED can explicitly control a transaction through using the methods of javax.jts.UserTransaction.

  • Container demarcation— The programmer does not write code to define when the transaction begins, commits, or rolls back. The EJB container instead defines this. The behavior of this object in a transaction is based on information in the transaction attribute fields of the deployment descriptor.

By far, the preferred way of managing a transaction (e.g., determining when it starts, and how it terminates) is through container demarcation. This is called declarative transaction management, since declarations in the deployment descriptor tell the container when to start and commit the transaction. To understand how this works, we should examine what values the transaction attribute can take on. Transaction attributes can be set on either the bean or the method level. (If it is set at the method level it overrides the setting, if any, on the bean level.) The values of this attribute are:

  • Mandatory— The client of this EJB must create a transaction (either programmatically or declaratively through container demarcation) before invocation of a method. If a transaction context is not present, a javax.transaction.TransactionRequired-Exception is thrown if the client is a remote client, or a javax.transaction.TransactionRequiredLocalException is thrown if the client is a local client. The execution of the EJB method will be associated with the client transaction (i.e., this object will participate in the transaction context associated with the calling thread).

  • NotSupported— Transactions are not supported by this EJB or method. If a client provides a transaction, it is suspended. All methods marked with this value will execute within an unspecified transaction context. However, if an externally created transaction is so suspended, the transaction will be resumed and propagated to other objects called in this thread after the completion of the marked method(s).

  • Required— The EJB requires that methods be executed within a transaction. If a client transaction is provided, it is used, and the execution of the method is associated with it. If no transaction context exists, a transaction context is created for this thread at the start of the method, and it commits when the method has completed. If other methods are called within this method, the transaction context is passed along with the method invocation. This is the default transaction setting if one is not explicitly defined for the bean.

  • RequiresNew— The EJB requires that a method be executed in a new transaction. If a client transaction is provided it is suspended for the method execution.[4] A new transaction is always created at the start of the method, and it commits when the method has completed.

    [4] The EJB Specification [Sun] only describes support for flat transactions and does not include support for nested transactions. Only one transaction may execute within an object at a time.

  • Supports— The EJB supports execution of the method in a transaction but does not require it. If this thread is associated with a transaction context the method execution will be associated with that transaction. If this thread is not associated with a transaction context, then the method executes in an unspecified transaction context.

To understand how transactions are propagated or passed by beans with different settings of this attribute, examine Figure derived from [Sun].

  • Never— A mixture of NotSupported and Mandatory. If a client provides a transaction context, then the method will throw a java.rmi.RemoteException if the client is a remote client, or a javax.ejb.EJBException if the client is a local client. On the other hand, if the client does not provide a transaction context, the method acts the same as in the NotSupported case.

Transaction attribute settings.

Transaction Attribute

Client Transaction

Transaction Associated with Bean Method

NotSupported

None

None

 

T!

None

Required

None

T2

 

T!

T1

Supports

None

None

 

T!

T1

RequiresNew

None

T2

 

T!

T2

Mandatory

None

ERROR

 

T!

T1

Never

None

None

 

T!

ERROR

Note that in Figure on the Required line, a transaction, T2, is created because the client does not have an existing transaction and the transaction attribute is Required. Also, note that in Mandatory, an error is produced because the client does not have an existing transaction when calling the method. Careful use of the transaction attributes can help to enforce application defined transactional integrity within a set of EJBs.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows