The easiest isolation level to understand is serializable, which mandates complete isolation. If we choose serializable as our isolation level, Paul will never see any of Brian's or Mary's changes until Paul begins a new transaction. From Paul's perspective, the database remains completely consistent and there are no side effects; Paul will see the same results for his query all four times because they all take place within a single transaction that is insulated from any other modifications. That sounds pretty ideal, right? So what more is there to talk about? Unfortunately, there is a lot of overhead associated with this setting. Using serializable vastly reduces the number of concurrent operations that may occur and can result in nasty performance problems involving database locks. As such, the serializable isolation level should be used sparingly, when the use case really requires absolute consistency and it's acceptable to risk the chance that concurrent transactions may be forced to abort with an error.

Relaxing isolation a bit by employing the repeatable read isolation level in our scenario would allow Paul to see any inserts that are committed, but not updates or deletes. In order to guarantee that rereads of the same row stay consistent, the underlying database will ordinarily implement either row-level, shared read locks or multiversioning. Under this isolation level setting, Paul would not see Brian's update or delete at any point in the scenario. However, Paul will see Mary's insert at step nine after she has committed her transaction. This side effect—where newly inserted and committed rows are visible to Paul's query (step nine) that weren't visible earlier (steps four and seven) within a single transaction (T1)—is known as a phantom read.

Read committed is the default isolation level used by most RDBMS vendors, including Oracle and PostgreSQL. This isolation level states that a transaction may read only data that has been committed in the database. When choosing read committed, Paul will see any changes made by Brian or Mary after their respective transactions have completed and been committed. This provides some data consistency while still delivering high concurrency. As with the repeatable read isolation level, Paul is still susceptible to phantom reads. As was the case with the repeatable read isolation level, Paul's query at step nine will return a new record that wasn't visible earlier in his transaction. When choosing read committed, Paul is also exposed to a second type of side effect; a nonrepeatable read. A nonrepeatable read occurs when rereads of the same row return different data within the same transaction. This becomes possible after Brian's update and delete are committed in step five. Unlike what happened under the serializable or repeatable read isolation levels, these row level modifications become visible to Paul in step seven, even though Paul read these two rows earlier and he's still in the context of his first and only transaction, T1. When in doubt, choose the read committed.

On the polar opposite end of the spectrum from serializable is the read uncommitted isolation level. If we employ read uncommitted for our scenario, there will be no transactional isolation whatsoever. Consequently, Paul's first three identical queries will all return different results. If Mary's commit in step eight succeeds, Paul's fourth query will return the same results as his third query.

At step four, Paul sees Brian's typo correction (SQL UPDATE) as well as the removal he performed (SQL DELETE) before Brian's transaction commits. This third side effect is commonly referred to as a dirty read because Paul is reading in tentative data. If Brian's commit fails at step five, forcing his transaction to roll back, the data Paul is looking at will be rendered completely inaccurate. Reading in Mary's insert at step seven, prior to her commit, is also representative of a dirty read because that too represents tentative data.

Choosing the read uncommitted isolation level exposes you to all three of the possible side effects. Intuitively, this represents a strategy that is not ideal. However, there is a silver lining with the read uncommitted isolation level. Because this isolation level offers the highest degree of concurrency, one can expect each of Paul, Brian, and Mary's SQL operations to be incredibly fast. You might adopt this isolation level when you need to emphasize speed and you're confident that your application can cope with the side effects. As with serializable, read uncommitted should only be considered for fringe use cases.

Spring offers several TransactionManager implementations, each of which fills the role of (drum roll please) managing transactions. TransactionManager instances typically extend the AbstractPlatformTransactionManager class, which in turn implements the PlatformTransactionManager interface. These classes form the foundation of Spring's transactional support, and provide the know-how to access, initiate, rollback, and commit transactions. The interface looks like this:

public interface PlatformTransactionManager {
    TransactionStatus getTransaction(TransactionDefinition definition)
       throws TransactionException;

    void commit(TransactionStatus status) throws TransactionException;

    void rollback(TransactionStatus status) throws TransactionException;
}

There are quite a few TransactionManager implementations. For example, the DataSourceTransactionManager is used for JDBC and iBATIS implementations. For our purposes, we are predominantly interested in Spring's ORM-based TransactionManager implementations: HibernateTransactionManager and JpaTransactionManager.

You'll even find TransactionManager implementations for JTA used by EJB. JTA is typically used to enable transactions to span across multiple databases and even disparate technologies, such as Java Message Service (JMS). These include the generic JtaTransactionManager and implementations for specific EJB servers like OC4JJtaTransactionManager for Oracle's server, WebLogicJtaTransactionManager for BEA's server, and WebSphereUowTransactionManager for IBM's server.

By adding the <tx:jta-transaction-manager/> XML tag to your Spring configuration, you can empower Spring to determine which JTA transaction manager to use, based on runtime information, so that you don't need to explicitly reference the platform-specific details in your configuration.

You might have noticed the TransactionStatus and TransactionDefinition interfaces that are part of the PlatformTransactionManager interface. You rarely need to use these interfaces yourself. They are set up by Spring's declarative transaction management (discussed in the next section), but they are still worth knowing about, as these details help to explain how Spring's transactional features work under the hood.

We will learn more about how these classes are used later in this chapter when we discuss programmatic transaction management.

Declarative programming employs metadata to define the requirements for a particular set of application logic, rather than coding the steps that define this behavior directly. Typically, you use declarative programming within the context of a framework, which is designed to analyze the metadata in order to tailor its behavior accordingly. Using declarative transaction management, therefore, implies that you define the rules or attributes that compose your transactions' behavior, rather than interspersing this logic directly in your code. As you can probably guess, Spring applies these cross-cutting concerns to your code by levering its excellent AOP support. However, because transactions are such a prevalent and critical feature, the AOP details are a bit abstracted to provide a clearer and more transaction-specific approach.

Spring has a fantastic annotation-driven approach for transaction management. An alternative is to use an XML-driven strategy based on Spring configuration. We will discuss both of these approaches, beginning with annotation-based transaction management, since you have seen examples of this in earlier chapters.

class ArtEntityServiceImpl implements ArtEntityService {

    @Transactional(rollbackFor=InvalidImageExeption.class,
                   readOnly=false,
                   timeout=30,
                   propagation=Propagation.SUPPORTS,
                   isolation=Isolation.DEFAULT)
    public void saveArtEntity(ArtEntity artEntity) throws InvalidImageException {
        this.getArtEntityDao().saveArtEntity(artEntity);
    }
}

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
            http://www.springframework.org/schema/context
            http://www.springframework.org/schema/context/spring-context-3.0.xsd
            http://www.springframework.org/schema/tx
            http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">

    <!-- JPA Entity Manager Factory -->
    <bean id="entityManagerFactory"
          class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
          p:dataSource-ref="galleryDataSource"/>

    <bean
       class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

<!-- Database LOB Handling -->
    <bean id="defaultLobHandler"
          class="org.springframework.jdbc.support.lob.DefaultLobHandler" />

    <!-- Read in DAOs from the JPA package -->
    <context:component-scan base-package="com.prospringhibernate.gallery.dao.jpa" />

<!-- Transaction Config -->
<bean id="transactionManager"
             class="org.springframework.orm.jpa.JpaTransactionManager"
             p:entityManagerFactory-ref="entityManagerFactory"/>

<tx:annotation-driven mode="aspectj" transaction-manager="transactionManager"/>

</beans>

<tx:advice id="txAdvice" >
    <tx:attributes>
        <tx:method name="save*" propagation="REQUIRED"/>
        <tx:method name="update*" propagation="REQUIRED"/>
        <tx:method name="delete*" propagation="REQUIRED"/>
        <tx:method name="*" propagation="SUPPORTS" read-only="true"/>
    </tx:attributes>
</tx:advice>

<aop:config>
    <aop:pointcut id="allServices"
                  expression="execution(*com.prospringhibernate.gallery.service.*.*(..))"/>
    <aop:advisor advice-ref="txAdvice" pointcut-ref="allServices"/>
</aop:config>

<aop:pointcut id="allServices"
           expression="@target(org.springframework.transaction.annotation.Transactional)"/>

<aop:pointcut
    id="allServices"
    expression="execution(*com.prospringhibernate.gallery.service.*.*(..)) &&
        @target(org.springframework.transaction.annotation.Transactional)"/>

<aop:pointcut id="allServices" expression ="bean(personService)"/>

<aop:pointcut id="allServices" expression ="bean(*Service) || bean(*Dao)"/>

We can't think of many real-world use cases for working with programmatic transactions rather than leveraging Spring's simpler declarative transaction support. However, understanding programmatic transactions can prove helpful in comprehending the way in which Spring transactions work under the hood.

To demonstrate how programmatic transactions work, we will rework the ArtEntityService example to use programmatic transactions, as follows;

public class ArtEntityServiceImpl implements ArtEntityService {

    private TransactionTemplate transactionTemplate;

    public ArtEntityServiceImpl(PlatformTransactionManager transactionManager) {
        this.transactionTemplate = new TransactionTemplate(transactionManager);
    }

    public Object saveArtEntity(ArtEntity artEntity) {
        return transactionTemplate.execute(
            new TransactionCallback() {
                public Object doInTransactionWithoutResult(TransactionStatus status) {
                    try {
                        this.getArtEntityDao().saveArtEntity(artEntity);

} catch (ImageErrorException e) {
                        status.setRollbackOnly();
                    }
                    return;
                }
            }
        );
    }

}

In this snippet, we rely on constructor injection to provide a reference to our JpaTransactionManager (which is an implementation of the PlatformTransactionManager interface). Using transactionManager, we create an instance of TransactionTemplate, which we use to wrap our persistence behavior within the scope of a transaction.

The usage of the TransactionTemplate should look very familiar to you. This is a common Spring idiom, and works in a similar fashion to the HibernateTemplate we use within our DAO classes. The key difference here is that we are using the TransactionTemplate to handle the boilerplate process of transactions, rather than database connection setup and closing.

To wrap our persistence code within a transaction, we call the execute method on our transactionTemplate property, passing in an anonymous implementation of TransactionCallback as a parameter. In the example, our service method does not return a value, so we implement the method doInTransactionWithoutResult. However, if we needed to return a value from our transaction, we would instead use doInTransaction.

Within the scope of the TransactionCallback, we are calling the same persistence code that we used in our annotation-based example. We delegate to our artEntityDao to do the heavy lifting. Notice, however, that we catch the ImageErrorException, and should the exception get thrown, we use the TransactionStatus parameter to rollback the transaction.

Clearly, this approach is not as clear or as elegant as using declarative transactions in Spring. Nevertheless, it is helpful to see how the various components fit together without relying on AOP to inject this behavior implicitly.

Batch applications can be a bit of a drag, especially with ORM frameworks. Both the database and the ORM framework need to reserve valuable resources for each operation performed in a transaction. The database needs to keep locks on the tables that you've changed. The ORM, for a variety of reasons, needs to cache the objects that you've persisted and read from the database. The more operations a transaction executes, the more resources the ORM and database need to dedicate to it.

Let's start out with the following example, which updates a whole bunch of records:

@Transactional(readOnly = false, propagation = Propagation.SUPPORTS)
public void batchProcessAll() {
    int count = dao.getCount();
    // do your ACID business in a big for loop
}

Here, we're attempting to update all of the data in a single transaction. Depending on the amount of data and system resources, this may not be possible, or it may lead to degraded performance for our application. Instead, we may be able to find a way to define smaller units that can be committed, which will free up some of the resources utilized by the database and ORM framework. However, the process of committing the transaction consumes resources as well. If we commit too often, we'll probably decrease performance. There's a balance between committing too often and too little—for example, committing after a certain number of items have been processed.

We can create a method that processes x number of units and commits after it completes. It's actually quite simple to set this up. We'll choose 100 as an arbitrary number of units of work.

// no transaction on this method anymore
public void batchProcessAll() {
    int count = dao.getCount();
    for(int i=0; i<count; i+= 100) {
        doMyUnit(i, i+100);
    }
}

@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void doMyUnit(int start, int finish) {
    // do your ACID business from the unit's
    // start to finish
    dao.flush();
}

Note the use of Propagation.REQUIRES_NEW. It tells Spring that a new transaction begins when the method gets invoked and commits when the method completes. It's just that simple to create and commit a transaction. There are many variables, ranging from server capacity to application load, to be able to prescribe an ideal batch size, so determining the best size for your application will likely require some trial and error.

Assume you have two databases, and you want to apply the right transactions to the right beans. You need to create two different transactionManagers that must be applied to the appropriate subsets of Spring beans. You can do that with some fancy AOP work.

Assume that you have already configured transactionManager1 and transactionManager2 beans. You'll need to start with the following XML:

<tx:advice id="txAdvice1" transaction-manager="transaction-manager1" >
    <tx:attributes>
        <tx:method name="save*" propagation="REQUIRED"/>
        <tx:method name="update*" propagation="REQUIRED"/>
        <tx:method name="delete*" propagation="REQUIRED"/>

<tx:method name="*" propagation="SUPPORTS" read-only="true"/>
    </tx:attributes>
</tx:advice>

<tx:advice id="txAdvice2" transaction-manager="transaction-manager2" >
    <tx:attributes>
        <tx:method name="save*" propagation="REQUIRED"/>
        <tx:method name="update*" propagation="REQUIRED"/>
        <tx:method name="delete*" propagation="REQUIRED"/>
        <tx:method name="*" propagation="SUPPORTS" read-only="true"/>
    </tx:attributes>
</tx:advice>

<aop:config>
    <aop:advisor advice-ref="txAdvice1" pointcut-ref="allDatabaseOneBeans"/>
    <aop:advisor advice-ref="txAdvice2" pointcut-ref="allDatabaseTwoBeans"/>
    <!-- Add pointcuts here -->
</aop:config>

The tx:advice element tells Spring what needs to be done, and the aop:config element tells Spring where it needs to be done.

The question now is what beans should have which advice? Some beans need txAdvice1; others need txAdvice2; and others may need both. Thankfully, Spring AOP provides several mapping options. You might chose to organize your classes into packages that differentiate between the two datasources to which they relate and apply an expression pointcut, or you can devise logical bean names that clearly infer which advice to apply. You can also create our own annotations, @Transaction1 and @Transaction2 for example, and use the expression="@target(...)" approach.

Let's go through a quick bean name example. Imagine we have two datasources: datasource1 and datasource2. Let's say that all of the datasource1 beans have ds1 as part of their bean name. For example, if PersonDao is intended to interface with datasource1, it would be called ds1.personDao. If PersonService depends on personDao as well as a DAO from datasource2, it should be called ds1.ds2.personService. Our pointcuts will look like the following:

<aop:pointcut id="allDatabaseOneBeans" expression ="bean(*ds1*)"/>
<aop:pointcut id="allDatabaseTwoBeans" expression ="bean(*ds2*)"/>

We've defined two pointcut expressions that utilize a bean-naming convention to properly infer which datasource and transactionManager to utilize for a given transaction.