Understanding EJB transactions

Transaction isolation

This is a property related to the database.

TRANSACTION_SERIALIZABLE—Simultaneously executing this transaction multiple times has the same effect as executing the transaction multiple times in a serial fashion. This is the most restrictive and should be avoided is most cases.This solves the problems of phantom reads by never letting any other transaction even read or update this data.
TRANSACTION_REPEATABLE_READ—Once the transaction reads a subset of data, repeated reads of the same data return the same values, even if other transactions have subsequently modified the data. This is the also restrictive but less than TRANSACTION_SERIALIZABLE and also should be avoided is most cases. This solves the problem of non repreatable reads.
TRANSACTION_READ_COMMITTED—The transaction can view only committed updates from other transactions. This is the default in servers like weblogic. This solves the problem of dirty reads.
TRANSACTION_READ_UNCOMMITTED—The transaction can view uncommitted updates from other transactions. This is least restrictive, but it is also makes dirty reads possible.

How does a transaction apply itslef to an EJB ?

How to declare what transaction scheme to use ?trans-attribute in ejb-jar.xml

Specifies how the container manages the transaction boundaries when delegating a method invocation to an enterprise bean's business method. Allowable value include:
* NotSupported
* Supports
* Required
* RequiresNew
* Mandatory
* Never

Note: Because clients do not provide a transaction context for calls to an MDB, MDBs that use container-managed transactions must have trans-attribute of Required.

If not specified, the EJB container issues a warning, and uses NotSupported for MDBs and Supports for other types of EJBs.

In a stateless session bean as well as an entity bean the transaction does not span method calls. In statefull session bean since there is a user session invloved the transaction can span various method call.

There is an interface called javax.ejb.SessionSynchronization which provides call back methods to the statefull session bean so as to know what is happening with the transaction:-
http://java.sun.com/products/ejb/javadoc-1.0/javax.ejb-javadoc/javax.ejb.SessionSynchronization.html

afterBegin

 public abstract void afterBegin() throws RemoteException

The afterBegin method notifies a session Bean instance that a new transaction has started, and that the subsequent business methods on the instance will be invoked in the context of the transaction.

The instance can use this method, for example, to read data from a database and cache the data in the instance fields.

This method executes in the proper transaction context.

Throws: RemoteException

Thrown if the instance could not perform the function requested by the container because of a system-level error.

beforeCompletion

 public abstract void beforeCompletion() throws RemoteException

The beforeCompletion method notifies a session Bean instance that a transaction is about to be committed. The instance can use this method, for example, to write any cached data to a database.

This method executes in the proper transaction context.

Note: The instance may still cause the container to rollback the transaction by invoking the setRollbackOnly() method on the instance context, or by throwing an exception.

Throws: RemoteException

Thrown if the instance could not perform the function requested by the container because of a system-level error.

afterCompletion

 public abstract void afterCompletion(boolean committed) throws RemoteException

The afterCompletion method notifies a session Bean instance that a transaction commit protocol has completed, and tells the instance whether the transaction has been committed or rolled back.

This method executes with no transaction context.

This method executes with no transaction context.

Parameters:

committed - True if the transaction has been committed, false if is has been rolled back.

Throws: RemoteException

Thrown if the instance could not perform the function requested by the container because of a system-level error.

However you can start a transaction in a method of a session bean and then call other some other bean's methods. This way you can propogate transactions.

Lets say you have a parent EJB and a child EJB.

All parent and child EJB methods have transaction as RequriesNew.
In this case it is suprising but true, that all unchecked and runtime exceptions in child mthods will cause the parent to roll back too. Checked application exceptions will have no effect on the parent. However here if the parent fails after the child has finished executing, the results of the child will not have any effect.

All parent and child EJB methods have transaction as Requries.
In this case too all unchecked and runtime exceptions in child methods will cause the parent to roll back too. Also they both have the same Transaction context as the parent here propogates the transaction to the child. Here if the parent fails after the child has finished executing, the results of the child will also roll back.

Nested transactions:
By default EJB's do not support nested transactions.
However one can simulate nested transactions by using a combination of the "parent and child EJB methods have transaction as Requries. " and "parent and child EJB methods have transaction as RequriesNew" or a combination of the above, type of architechture. You can not let parent rollback by using requiresNew on the child EJB and then you have two seperate transactions independent of each other.Also You can force a parent rollback by having all child EJB's that are called throw up an excpetion like " ForceRollbackParentException and make sure that the parent has not caught it.