ACID

ACID refers to the four properties that define a reliable transaction: Atomicity, Consistency, Isolation, and Durability (described in Table 9-1). To explain these properties, I’ll take the classical example of a banking transfer: you need to debit your savings account to credit your current account.

When you transfer money from one account to the other, you can imagine a sequence of database accesses: the savings account is debited using a SQL update statement, the current account is credited using a different update statement, and a log is created in a different table to keep track of the transfer. These operations have to be done in the same unit of work (Atomicity) because you don’t want the debit to occur but not the credit. From the perspective of an external application querying the accounts, only when both operations have been successfully performed are they visible (Isolation). With isolation, the external application cannot see the interim state when one account has been debited and the other is still not credited (if it could, it would think the user has less money than she really does). Consistency is when transaction operations (either with a commit or a rollback) are performed within the constraints of the database (such as primary keys, relationships, or fields). Once the transfer is completed, the data can be accessed from other applications (Durability).

Read Conditions

Transaction isolation can be defined using different read conditions (dirty reads, repeatable reads, and phantom reads). They describe what can happen when two or more transactions operate on the same data at the same time. Depending on the level of isolation you put in place you can totally avoid or allow concurrent access.

• Dirty reads: Occur when a transaction reads uncommitted changes made by the previous transaction.
• Repeatable reads: Occur when the data read are guaranteed to look the same if read again during the same transaction.
• Phantom reads: Occur when new records added to the database are detectable by transactions that started prior to the insert. Queries will include records added by other transactions after their transaction has started.

Transaction Isolation Levels

Databases use several different locking techniques to control how transactions access data concurrently. Locking mechanisms impact the read condition described previously. Isolation levels are commonly used in databases to describe how locking is applied to data within a transaction. The four types of isolation levels are

• Read uncommitted (less restrictive isolation level): The transaction can read uncommitted data. Dirty, nonrepeatable, and phantom reads can occur.
• Read committed: The transaction cannot read uncommitted data. Dirty reads are prevented but not nonrepeatable or phantom reads.
• Repeatable read: The transaction cannot change data that are being read by a different transaction. Dirty and nonrepeatable reads are prevented but phantom reads can occur
• Serializable (most restrictive isolation level): The transaction has exclusive read. The other transactions can neither read nor write the same data.

Generally speaking, as the isolation level becomes more restrictive the performance of the system decreases because transactions are prevented from accessing the same data. However, the  isolation level enforces data consistency. Note that not all RDBMS (Relational Database Management Systems) implement these four isolation levels.

JTA Local Transactions

Several components have to be in place for transactions to work and follow the ACID properties. Let’s first take the simplest example of an application performing several changes to a single resource (e.g., a database). When there is only one transactional resource, all that is needed is a local JTA transaction. A resource local transaction is a transaction that you have with a specific single resource using its own specific API. Figure 9-1 shows the application interacting with a resource through a transaction manager and a resource manager.

The components shown in Figure 9-1 abstract most of the transaction-specific processing from the application.

• The transaction manager is the core component responsible for managing the transactional operations. It creates the transactions on behalf of the application, informs the resource manager that it is participating in a transaction (an operation known as enlistment), and conducts the commit or rollback on the resource manager.
• The resource manager is responsible for managing resources and registering them with the transaction manager. An example of a resource manager is a driver for a relational database, a JMS resource, or a Java connector.
• The resource is the persistent storage from which you read or write (a database, a message destination, etc.).

It is not the application’s responsibility to preserve ACID properties. The application just decides to either commit or roll back the transaction, and the transaction manager prepares all the resources to successfully make it happen.

Distributed Transactions and XA

As you’ve just seen, a transaction using a single resource (shown previously in Figure 9-1) is called a JTA local transaction. However, many enterprise applications use more than one resource. Returning to the example of the fund transfer, the savings account and the current account could be in separate databases. You would then need transaction management across several resources, or resources that are distributed across the network. Such enterprise-wide transactions require special coordination involving XA and the Java Transaction Service (JTS).

Figure 9-2 shows an application that uses transaction demarcation across several resources. This means that, in the same unit of work, the application can persist data in a database and send a JMS message, for example.

To have a reliable transaction across several resources, the transaction manager needs to use an XA (eXtended Architecture) resource manager interface. XA is a standard specified by the Open Group (www.opengroup.org) for distributed transaction processing (DTP) that preserves the ACID properties. It is supported by JTA and allows heterogeneous resource managers from different vendors to interoperate through a common interface. XA uses a two-phase commit (2pc) to ensure that all resources either commit or roll back any particular transaction simultaneously.

In our fund transfer example, suppose that the savings account is debited on a first database, and the transaction commits successfully. Then the current account is credited on a second database, but the transaction fails. We would have to go back to the first database and undo the committed changes. To avoid this data inconsistency problem, the two-phase commit performs an additional preparatory step before the final commit as shown in Figure 9-3. During phase 1, each resource manager is notified through a “prepare” command that a commit is about to be issued. This allows the resource managers to declare whether they can apply their changes or not. If they all indicate that they are prepared, the transaction is allowed to proceed, and all resource managers are asked to commit in the second phase.

Most of the time, the resources are distributed across the network (see Figure 9-4). Such a system relies on JTS. JTS implements the Object Management Group (OMG) Object Transaction Service (OTS) specification, allowing transaction managers to participate in distributed transactions through Internet Inter-ORB Protocol (IIOP). Compared to Figure 9-2, where there is only one transaction manager, Figure 9-4 allows the propagation of distributed transactions using IIOP. This allows transactions to be distributed across different computers and different databases from different vendors. JTS is intended for vendors who provide the transaction system infrastructure. As an EJB developer, you don’t have to worry about it; just use JTA, which interfaces with JTS at a higher level.

A Brief History of JTA

JTA is the general API for managing transactions in Java EE. It allows you to start, commit, and roll back transactions in a resource neutral way. If more than one resource participates in such a transaction, JTA also allows you to do XA transactions.

JTA 1.0 was introduced in 1999 and had some maintenance releases to reach a 1.1 version in 2002. It remained unchanged for a decade and was finally updated to JTA 1.2 with Java EE 7.

What’s New in JTA 1.2?

Historically in Java EE, transactions were delegated to EJBs so developers didn’t have to use the JTA APIs directly in their code. Both JTA (JSR 907) and EJBs (JSR 345) had been around since 1999. The EJB specification kept on evolving but not JTA, which was already a pretty mature and solid specification. With Managed Bean alignment happening in Java EE 7, one of the biggest challenges was to bring transactions to Managed Beans and not only EJBs. To accomplish that, the JTA specification needed to be updated. JTA 1.2 brings support for container-managed transactions independent of EJB and a @TransactionScope annotation for CDI bean scope.

The JTA API consists of classes and interfaces grouped in two packages described in Table 9-2.

Reference Implementation

The reference implementation for JTA is the GlassFish Transaction Manager. It is a module of GlassFish but is not usable outside the server itself. Other open source or commercial stand-alone JTA implementations are available such as JBoss Transaction Manager, Atomikos, and Bitronix JTA.

Container-Managed Transactions

When managing transactions declaratively, you delegate the demarcation policy to the container. You don’t have to explicitly use JTA in your code (even if JTA is used underneath); you can leave the container to demarcate transaction boundaries by automatically beginning and committing transactions based on metadata. The EJB container provides transaction management services to session beans and MDBs (see Chapter 13 for more on MDBs). In an enterprise bean with a container-managed transaction, the EJB container sets the boundaries of the transactions.

In Chapter 7, you saw several examples of session beans, annotations, and interfaces, but never anything specific to transactions. Listing 9-1 shows the code of a stateless session bean using CMT. As you can see, there is no extra annotation added or any special interface to implement. EJBs are by nature transactional. With configuration by exception, all the transaction management defaults are applied (REQUIRED is the default transaction attribute as explained later in this section).

Listing 9-1.  A Stateless Bean with CMT

@Stateless
public class ItemEJB {
 
  @PersistenceContext(unitName = "chapter09PU")
  private EntityManager em ;
  @Inject
  private InventoryEJB inventory ;
 
  public List<Book> findBooks() {
    TypedQuery<Book> query = em .createNamedQuery(FIND_ALL, Book.class);
    return query.getResultList();
  }
 
  public Book createBook(Book book) {
    em.persist(book);
    inventory.addItem(book);
    return book;
  }
}

You might ask what makes the code in Listing 9-1 transactional. The answer is the container. Figure 9-5 shows what happens when a client invokes the createBook() method. The client call is intercepted by the container, which checks immediately before invoking the method whether a transaction context is associated with the call. By default, if no transaction context is available, the container begins a new transaction before entering the method and then invokes the createBook() method. Once the method exits, the container automatically commits the transaction or rolls it back (if a particular type of exception is thrown, as you’ll see later in the “Exceptions and Transactions” section).

The default behavior is that whatever transaction context is used for 3:createBook() (from the client or created by the container) is applied to 4:addItem(). The final commit happens if both methods have returned successfully. This behavior can be changed using metadata (annotation or XML deployment descriptor). Depending on the transaction attribute you choose (REQUIRED, REQUIRES_NEW, SUPPORTS, MANDATORY, NOT_SUPPORTED, or NEVER), you can affect the way the container demarcates transactions: on a client invocation of a transactional method, the container uses the client’s transaction, runs the method in a new transaction, runs the method with no transaction, or throws an exception. Table 9-3 defines the transaction attributes.

Figure 9-6 illustrates all the possible behaviors that an EJB can have depending on the presence or not of a client’s transaction context. For example, if the createBook() method doesn’t have a transaction context (top part of the figure) and invokes addItem() with a MANDATORY attribute, an exception is thrown. The bottom part of Figure 9-6 shows the same combinations but with a client that has a transaction context.

To apply one of these six demarcation attributes to your session bean, you have to use the @javax.ejb.TransactionAttribute annotation or the deployment descriptor (setting the <trans-attribute> element in the ejb-jar.xml). These metadata can be applied either to individual methods or to the entire bean. If applied at the bean level, all business methods will inherit the bean’s transaction attribute value. Listing 9-2 shows how the ItemEJB uses a SUPPORT transaction demarcation policy and overrides the createBook() method with REQUIRED.

Listing 9-2.  A Stateless Bean with CMT

@Stateless
@TransactionAttribute(TransactionAttributeType.SUPPORTS)
public class ItemEJB {
 
  @PersistenceContext(unitName = "chapter09PU")
  private EntityManager em;
  @Inject
  private InventoryEJB inventory;
 
  public List<Book> findBooks() {
    TypedQuery<Book> query = em.createNamedQuery(FIND_ALL, Book.class);
    return query.getResultList();
  }
 
  @TransactionAttribute(TransactionAttributeType.REQUIRED)
  public Book createBook(Book book) {
    em.persist(book);
    inventory.addItem(book);
    return book;
  }
}

@Stateless
public class InventoryEJB {
 
  @PersistenceContext(unitName = "chapter09PU")
  private EntityManager em;
  @Resource
  private SessionContext ctx ;
 
  public void oneItemSold(Item item) {
    item.decreaseAvailableStock();
    sendShippingMessage();
 
    if (inventoryLevel(item) == 0)
      ctx.setRollbackOnly();
  }
}

@Stateless
public class InventoryEJB {
 
  @PersistenceContext(unitName = "chapter09PU")
  private EntityManager em;
 
  public void oneItemSold(Item item) throws InventoryLevelTooLowException{
    item.decreaseAvailableStock();
    sendShippingMessage();
 
    if (inventoryLevel(item) == 0)
      throw new InventoryLevelTooLowException();
  }
}

@ApplicationException(rollback = true)
public class InventoryLevelTooLowException extends Exception {
 
  public InventoryLevelTooLowException() { }
 
  public InventoryLevelTooLowException(String message) {
    super(message);
  }
}

Bean-Managed Transactions

With CMT, you leave the container to do the transaction demarcation just by specifying a transaction attribute and using the session context or exceptions to mark a transaction for rollback. In some cases, the declarative CMT may not provide the demarcation granularity that you require (e.g., a method cannot generate more than one transaction). To address this issue, EJBs offer a programmatic way to manage transaction demarcations with BMT. BMT allows you to explicitly manage transaction boundaries (begin, commit, rollback) using JTA.

To turn off the default CMT demarcation and switch to BMT mode, a bean simply has to use the @javax.ejb.TransactionManagement annotation (or the XML equivalent in the ejb-jar.xml file) as follows:

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class ItemEJB {...}

With BMT demarcation, the application requests the transaction, and the EJB container creates the physical transaction and takes care of a few low-level details. Also, it does not propagate transactions from one BMT to another.

The main interface used to carry out BMT is javax.transaction.UserTransaction. It allows the bean to demarcate a transaction, get its status, set a timeout, and so on. The UserTransaction is instantiated by the EJB container and made available through dependency injection, JNDI lookup, or the SessionContext (with the SessionContext.getUserTransaction() method). Table 9-5 describes the API.

Listing 9-6 shows how to develop a BMT bean. First of all, we get a reference of the UserTransaction using injection through the @Resource annotation. The oneItemSold() method begins the transaction, does some business processing, and then, depending on some business logic, commits or rolls back the transaction. Notice also that the transaction is marked for rollback in the catch block (I’ve simplified exception handling for better readability).

Listing 9-6.  A Stateless Bean with BMT

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class InventoryEJB {
 
  @PersistenceContext(unitName = "chapter09PU")
  private EntityManager em;
  @Resource
  private UserTransaction ut;
 
  public void oneItemSold(Item item) {
    try {
      ut.begin();
 
      item.decreaseAvailableStock();
      sendShippingMessage();
 
      if (inventoryLevel(item) == 0)
        ut.rollback();
      else
        ut.commit();
 
    } catch (Exception e) {
      ut.rollback();
    }
    sendInventoryAlert();
  }
}

The difference with the CMT code shown in Listing 9-3 is that with CMT the container starts the transaction before the method execution and commits it immediately after. With the BMT code shown in Listing 9-6, you manually define transaction boundaries inside the method itself.

Exceptions and Transactions

Exceptions and transactions are slightly different in Managed Beans than in EJBs. As in EJBs, they use the same default exception handling: application exceptions (i.e., checked exceptions) do not result in the transactional interceptor marking the transaction for rollback, and system exceptions (i.e., unchecked exceptions) do. But this default behavior can be overridden in the @Transactional annotation using the rollbackOn and dontRollbackOn attributes. When you specify a class for either of these attributes, the designated behavior applies to subclasses of that class as well. If you specify both attributes, dontRollbackOn takes precedence.

To override the default behavior and cause transactions to be marked for rollback for all application exceptions you need to write the following:

@Transactional(rollbackOn={Exception.class})

On the other hand, if you want to prevent transactions from being marked for rollback by the interceptor when an IllegalStateException (unchecked exception) or any of its subclasses is caught, you can use the dontRollbackOn as follows:

@Transactional(dontRollbackOn={IllegalStateException.class})

You can use both attributes to refine the transactional behavior. Each attribute takes an array of classes and can be used as follows:

@Transactional(rollbackOn={SQLException.class},
           dontRollbackOn={SQLWarning.class, ArrayIndexOutOfBoundsException.class})