Transactions

Transaction management is one of the key features of the EJB container. Although the concept of transactions itself is generic in nature and applicable to wide variety of use cases, in the Java EE (and EJB) context, transaction management related capabilities allow for a seamless integration between EJB and other specifications such as JPA (EJBs serve as the gateway for persistence related operations in Java EE applications), JMS etc.

@TransactionManagement

This (class level) annotation is used to convey as to who will be manage the transaction related details - the container itself (automatic & declarative management) or the bean developer (manual & programmatic based). It's possible values are defined by the enum javax.ejb.TransactionManagementType

• CONTAINER: container provides automatic transaction management (default)

• BEAN: transaction demarcation is provided by the bean developer

package ejbap.tx;

import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.transaction.UserTransaction;

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class BeanManagedTx {
    @Resource
    private UserTransaction uTx;

    public void save() throws Exception{
        try {
            uTx.begin();
            //perform operation
            uTx.commit();
        } catch (Exception ex) {
            uTx.rollback();
        } 
    }
}

@TransactionAttribute

This annotation defines the transactional semantic of the method it is applied on.

Notable aspects

• Applicable for CONTAINER managed transactions only

• It can be applied at a class as well as method level. In case of a conflict b/w the two, the method level annotation takes precedence

javax.ejb.TransactionAttributeType defines all the possible values and what their usage implies

• REQUIRED: (default) the method executes in the caller's transaction context (if any)

• REQUIRED_NEW: container starts new transaction, irrespective of the caller's transactional context state

• MANDATORY: the method needs to be invoked by the client in scope of an existing transaction (else an exception is thrown)

• NEVER: no transactional context would be associated with the method and the caller gets an exception in case it calls the method within a transaction

• NOT_SUPPORTED: an unspecified transactional context is associated with the method

• SUPPORTS: the method executes in the caller's transaction context (if any) otherwise the context is unspecified

Transaction lifecycle listeners

The below (callback style) annotations are applicable only to Stateful session beans using Container Managed transactions. These are similar to @PostConstruct & @PreDestroy i.e. just like the these annotations mark methods for lifecycle events, the below mentioned annotations allow methods to listen to transaction related events triggered by the container

@AfterBegin

The method decorated with this annotation is 'called-back' by the container after a transaction starts

@BeforeCompletion

This annotation marks a method to be called just prior to completion (commit/rollback) of a transaction.

@AfterCompletion

A method decorated with this annotation is called back at the end of transactional boundary (consisting of one or more methods). It should declare a boolean argument to accpet the transaction status - committed (true) or rollback (false)

The methods decorated with the aforementioned annotations have a few constraints

• they should not accept any arguments

• their return type can only be void

• final or static modifier is disallowed