As we mentioned earlier, the TransactionDefinition interface controls the properties of a transaction. Let's take a more detailed look at the TransactionDefinition interface (see Listing 16-1) and describe its methods.

public interface TransactionDefinition {
    int getPropagationBehavior();
    int getIsolationLevel();
    int getTimeout();
    boolean isReadOnly();
}

The simple and obvious methods of this interface are getTimeout(), which returns the time (in seconds) in which the transaction must complete, and isReadOnly(), which indicates whether the transaction is read-only. The transaction manager implementation can use this last value to optimize transaction execution and to make sure that the transaction is performing only reads.

The other two methods, getPropagationBehavior() and getIsolationLevel(), need to be discussed in more detail. We begin with getIsolationLevel, which controls what changes to the data other transactions see. Table 16-1 lists the transaction isolation levels you can use and explains what changes made in the current transaction other transactions can access.

Choosing the appropriate isolation level is very important for the consistency of the data, but the choices you make can have a great impact on performance. The highest isolation level, TransactionDefinition.ISOLATION_SERIALIZABLE, is particularly expensive to maintain.

The getPropagationBehavior method specifies what Spring does when your code requests a new transaction. The values for this method are listed in Table 16-2.

The TransactionStatus interface, shown in Listing 16-2, allows a transaction manager to control transaction execution. The code can check whether the transaction is a new one or whether it is a read-only transaction. You can also use the TransactionStatus reference to initiate a rollback.

public_interface_TransactionStatus_{
    boolean_isNewTransaction();
    void_setRollbackOnly();
    boolean_isRollbackOnly();
}

The methods of the TransactionStatus interface are fairly self-explanatory; the most notable one is setRollbackOnly(), which marks the transaction as uncommittable. In other words, the only operation you can perform after calling setRollbackOnly() is a rollback. In most cases, the transaction manager will detect this and end the transaction immediately after it notices that it would have to commit. The pseudo code in Listing 16-3 demonstrates this.

begin
SQL: select * from t_user;
Java: setRollbackOnly();
SQL: select * from t_user_address where user = ?
SQL: update t_user_address set primary = 1 where id = ?
SQL: select * from t_product

After the call to setRollbackOnly(), most databases allow the next select statement to execute but will fail on the update statement—it would be pointless to perform the update; because the transaction is read-only, the modification would not be committed.

The PlatformTransactionManager interface uses the TransactionDefinition and TransactionStatus interfaces to create and manage transactions. The actual implementations of this interface must have detailed knowledge of the transaction manager. The DataSourceTransactionManager controls transactions performed on JDBC Connection instances obtained from a DataSource; HibernateTransactionManager controls transactions performed on a Hibernate session; JdoTransactionManager manages JDO transactions; and JtaTransactionManager delegates transaction management to JTA.

Before we can begin discussing transactional management, we need to write the necessary support code. Let's begin with the SQL code in Listing 16-4 that creates the t_account table and inserts several testing accounts.

create table t_account (
    id number(19, 0) not null,
    sort_code varchar2(6) not null,

number_ varchar2(8) not null,
    balance number(19, 2) not null,
    constraint pk_account primary key (id)
)
/

insert into t_account (id, sort_code, number_, balance)
               values (1, '011001', '12345678', 1000.0)
/
insert into t_account (id, sort_code, number_, balance)
               values (2, '011001', '87654321', 100.0)
/
insert into t_account (id, sort_code, number_, balance)
               values (3, '011001', '10203040', 0.0)
/
insert into t_account (id, sort_code, number_, balance)
               values (4, '011001', '50607080', 30.0)
/
insert into t_account (id, sort_code, number_, balance)
               values (5, '011001', '10000000', 1000000.0)
/

There is nothing unusual about the SQL code; if you are not using an Oracle 10g database, you may need to tweak the SQL syntax to make the code run in your particular database. Next, we need to look at the Account and AccountIdentity classes and the BalanceMutator interface. For brevity, we show the two classes and interface in Listing 16-5.

Account.java:
public class Account {
    private Long id;
    private AccountIdentity identity;
    private BigDecimal balance;

    public void changeBalance(BalanceMutator mutator) {
        this.balance = mutator.mutate(this.balance);
    }

    // getters and setters
}

AccountIdentity.java:
public final class AccountIdentity implements Serializable {
    private static final long serialVersionUID = 3287882727785753918L;
    private String sortCode;
    private String number;

    public AccountIdentity() {
    }

    public AccountIdentity(String sortCode, String number) {
        Assert.notNull(sortCode, "The 'sortCode' argument must not be null.");
        Assert.notNull(number, "The 'number' argument must not be null.");

this.sortCode = sortCode;
        this.number = number;
    }
    ...
    // getters and setters
}

BalanceMutator.java:
public interface BalanceMutator {

    BigDecimal mutate(BigDecimal balance);

}

You can see that the Account class has a synthetic identity (Long id). The synthetic identity is the implementation detail: we need the synthetic ID in our code, but it is meaningless to the users; they use the account number and sort code to identify their accounts. The Account class has only one significant method: changeBalance(BalanceMutator). This method uses the BalanceMutator instance to update the balance of the account.

Next, we take a look at the sample application's data access layer. For simplicity, we will use the SimpleJdbcTemplate (go to Chapter 9 for more details on Spring JDBC support). We take an approach typical for Spring applications: we create the AccountDao interface and a single implementation, JdbcAccountDao. Listing 16-6 shows the source code of both the interface and the implementation.

AccountDao.java:
public interface AccountDao {

    void save(Account account);

    Account getByIdentity(AccountIdentity accountIdentity);

}

JdbcAccountDao.java
public class JdbcAccountDao extends SimpleJdbcDaoSupport implements AccountDao {
    private static final String INSERT_SQL =
            "insert into t_account (id, sort_code, number_, balance) values " +
                    "(?, ?, ?, ?)";
    private static final String UPDATE_SQL =
            "update t_account set balance=? where id=?";
    private static final String SELECT_SQL =
            "select id, sort_code, number_, balance from t_account " +
                    "where sort_code=? and number_=?";

public void save(Account account) {
        if (account.getId() == null) {
            // insert
            getSimpleJdbcTemplate().update(INSERT_SQL,
                    account.getId(),
                    account.getIdentity().getSortCode(),
                    account.getIdentity().getNumber(),
                    account.getBalance());
        } else {
            // update
            getSimpleJdbcTemplate().update(UPDATE_SQL,
                    account.getBalance(),
                    account.getId());
        }
    }

    public Account getByIdentity(AccountIdentity accountIdentity) {
        return getSimpleJdbcTemplate().queryForObject(SELECT_SQL,
                new ParameterizedRowMapper<Account>() {
                    public Account mapRow(ResultSet rs, int rowNumber)
                            throws SQLException {

                        Account account = new Account();
                        account.setId(rs.getLong(1));
                        AccountIdentity identity = new AccountIdentity(
                                rs.getString(2),
                                rs.getString(3)
                        );
                        account.setIdentity(identity);
                        account.setBalance(rs.getBigDecimal(4));
                        return account;
                    }
                }, accountIdentity.getSortCode(), accountIdentity.getNumber());
    }
}

We have tried to keep the code as simple as possible; keep in mind that we are not showing Spring JDBC, just implementing the data access layer code to demonstrate Spring transaction management. Finally, we implement the BankServiceSupport; we will use this class as the superclass for our transactional BankService implementations. To that effect, the BankServiceSupport implements the BankService methods as protected methods with the do prefix. Listing 16-7 shows the BankServiceSupport implementation.

public abstract class BankServiceSupport {
    private AccountDao accountDao;

    protected abstract static class BalanceMutatorSupport
            implements BalanceMutator {
        private BigDecimal amount;

BalanceMutatorSupport(BigDecimal amount) {
            Assert.notNull(amount, "The 'amount' argument must not be null.");
            this.amount = amount;
        }

        protected final BigDecimal getAmount() {
            return this.amount;
        }

        protected abstract BigDecimal doMutate(BigDecimal balance);

        public final BigDecimal mutate(BigDecimal balance) {
            return doMutate(balance);
        }
    }

    protected static class CreditBalanceMutator
            extends BalanceMutatorSupport {

        CreditBalanceMutator(BigDecimal amount) {
            super(amount);
        }

        protected BigDecimal doMutate(BigDecimal balance) {
            return balance.add(getAmount());
        }
    }

    protected static class NoOverdraftDebitBalanceMutator
            extends BalanceMutatorSupport {

        NoOverdraftDebitBalanceMutator(BigDecimal amount) {
            super(amount);
        }

        protected BigDecimal doMutate(BigDecimal balance) {
            BigDecimal result = balance.subtract(getAmount());
            if (result.compareTo(new BigDecimal(0)) < 0)
                throw new InsufficientFundsException(getAmount().subtract(balance));
            return result;
        }
    }

    protected void doTransfer(AccountIdentity from, AccountIdentity to,
                         BigDecimal amount) {
        Account fromAccount = this.accountDao.getByIdentity(from);
        if (fromAccount == null) throw new UnknownAccount(from);
        Account toAccount = this.accountDao.getByIdentity(to);
        if (toAccount == null) throw new UnknownAccount(to);

        fromAccount.changeBalance(new NoOverdraftDebitBalanceMutator(amount));
        toAccount.changeBalance(new CreditBalanceMutator(amount));

        this.accountDao.save(fromAccount);
        this.accountDao.save(toAccount);
    }

    protected BigDecimal doGetBalance(AccountIdentity accountIdentity) {
        Account account = this.accountDao.getByIdentity(accountIdentity);
        if (account == null) throw new UnknownAccount(accountIdentity);
        return account.getBalance();
    }

public void setAccountDao(AccountDao accountDao) {
        this.accountDao = accountDao;
    }
}

The doTransfer and doGetBalance methods implement the functionality of the BankService.transfer and BankService.getBalance methods; we have implemented them as protected methods because we will create different subclasses of the BankServiceSupport to demonstrate the different transaction management techniques Spring offers. Let's complete our nontransactional code with a nontransactional implementation of the BankServiceSupport class (see Listing 16-8).

public class DefaultBankService extends BankServiceSupport
        implements BankService {

    public void transfer(AccountIdentity from, AccountIdentity to,
                         BigDecimal amount) {
        doTransfer(from, to, amount);
    }

    public BigDecimal getBalance(AccountIdentity accountIdentity) {
        return doGetBalance(accountIdentity);
    }
}

The last pieces of the sample application are the Spring XML configuration files. We will split the configuration into two files: dao-context.xml and svc-context-*.xml. The dao-context.xml file will define the dataSource and accountDao beans; the svc-context-*.xml file will define the bankService bean. Listing 16-9 shows the dao-context.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       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.xsd">


    <bean id="dataSource"
        class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
        <property name="url"
            value="jdbc:oracle:thin:@oracle.devcake.co.uk:1521:INTL"/>
        <property name="username" value="PROSPRING"/>
        <property name="password" value="x******6"/>
    </bean>

    <bean id="transactionManager"
       class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource"/>
    </bean>

    <bean id="accountDao"

class="com.apress.prospring2.ch16.dao.jdbc.JdbcAccountDao">
        <property name="dataSource" ref="dataSource"/>
    </bean>

</beans>

There are no surprises here: the dataSource bean is the Apache DBCP implementation of the DataSource, and we use the Oracle 10g database. The accountDao bean is the JdbcAccountDao implementation from Listing 16-6. To verify that the application works without Spring transaction support, we will create the svc-context-nt.xml file (see Listing 16-10).

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       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.xsd">


    <bean id="bankService"
          class="com.apress.prospring2.ch16.services.DefaultBankService">
        <property name="accountDao" ref="accountDao"/>
    </bean>
</beans>

The final piece is the sample application that creates the ClassPathXmlApplicationContext and uses the bankService bean to transfer some virtual money between two accounts. Listing 16-11 shows a simple application that displays the account balances, transfers some money, and displays the final balances.

public class Main {

    public static void main(String[] args) {
        ApplicationContext ac = new ClassPathXmlApplicationContext(
                new String[] {
                        "/META-INF/spring/*-context.xml",
                        "/META-INF/spring/*-context-nt.xml"
                }
        );
        BankService bankService = (BankService) ac.getBean("bankService");
        final AccountIdentity a1 = new AccountIdentity("011001", "12345678");
        final AccountIdentity a2 = new AccountIdentity("011001", "10203040");

        System.out.println("Before");
        System.out.println(a1 + ": " + bankService.getBalance(a1));
        System.out.println(a2 + ": " + bankService.getBalance(a2));
        try {
            bankService.transfer(a1, a2, new BigDecimal("200.00"));
        } catch (Exception ignored) {

}
        System.out.println("After");
        System.out.println(a1 + ": " + bankService.getBalance(a1));
        System.out.println(a2 + ": " + bankService.getBalance(a2));
    }

}

Using the data we inserted in the SQL script in Listing 16-4, the application runs and prints the following:

Before
AccountIdentity {01-10-01 1234-5678}: 1000
AccountIdentity {01-10-01 1020-3040}: 0
After
AccountIdentity {01-10-01 1234-5678}: 800
AccountIdentity {01-10-01 1020-3040}: 200

The application works: it can find an account in the database using the AccountIdentity object, modify the amount in each account, and persist it to the database. The only trouble is that the debit and credit operations are not tied together. If the credit operation fails, the system will not reverse the debit operation: in other words, we take money out of the payer account, fail to pay it into the payee account, and the money is lost. We need to ensure that the debit and credit operations are treated as a single command. Accountants would also like to see that the amounts transferred match—the account records need to be consistent at all times. Also, we need to make sure that while we are debiting the payer account, the account holder cannot use an ATM card to withdraw more money than there would be when the transfer completes. Finally, we also need to guarantee that once we complete the transfer, the information about the transfer will survive even if the database server goes down. In short, our transfer method needs to conform to the ACID requirements.

Before we begin discussing the different transaction management approaches, we need to write code that will simulate possible problems. We will modify the JdbcAccountDao class to fail randomly; Listing 16-12 shows the unreliable implementation of JdbcAccountDao.

public class JdbcAccountDao extends SimpleJdbcDaoSupport implements AccountDao {
    ...

    public void save(Account account) {
        Grinch.ruin();
        if (account.getId() == null) {
            // insert
            getSimpleJdbcTemplate().update(INSERT_SQL,
                    account.getId(),
                    account.getIdentity().getSortCode(),
                    account.getIdentity().getNumber(),
                    account.getBalance());
        } else {
            // update
            getSimpleJdbcTemplate().update(UPDATE_SQL,
                    account.getBalance(),
                    account.getId());
        }
    }
    ...
}

The Grinch.ruin() method throws a RuntimeException randomly, which is precisely what we need in order to demonstrate transaction management fully. We complete the nontransactional code with Listing 16-13, which shows the Grinch class.

public final class Grinch {
    private static final Random RND = new Random();
    private static final String MESSAGE = "Muhehe! It's broken now.";

    private Grinch() {

    }

    public static void ruin() {
        if (RND.nextInt() % 3 == 0) {
            System.out.println(MESSAGE);
            throw new RuntimeException(MESSAGE);
        }
    }

}

If we wanted to use programmatic transaction control in more than one area of the system, we should refactor the way we interact with the PlatformTransactionManager. If we take a closer look at the transfer method, we can see that we have some common code that surrounds some specific code. This calls for the template method pattern, and Spring transaction support provides the TransactionTemplate class that implements the common code for the programmatic transaction management. All we have to do is supply the TransactionCallback implementation; its doInTransaction method represents the specialized section of the algorithm in the template method pattern. Listing 16-16 shows the ProgrammaticTxBankService using TransactionTemplate.

public class ProgrammaticTxBankService
        extends BankServiceSupport implements BankService{
    private TransactionTemplate transactionTemplate;

    public void transfer(final AccountIdentity from,
                         final AccountIdentity to,
                         final BigDecimal amount) throws Throwable {
        this.transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            protected void doInTransactionWithoutResult(TransactionStatus status) {
                doTransfer(from, to, amount);
            }
        });
    }

    public BigDecimal getBalance(AccountIdentity accountIdentity) {
        return doGetBalance(accountIdentity);
    }

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

You can see that the preceding code is much simpler: all the transaction creation and exception-handling code is in the TransactionTemplate. Also notice that we have not implemented the TransactionCallback interface directly. Instead, we have chosen to implement the abstract class TransactionCallbackWithoutResult. This was only for convenience: the TransactionCallback.doInTransaction implementation must return Object, but we do not want to return anything at all. The TransactionCallbackWithoutResult is an abstract class that implements the TransactionCallback.doInTransaction method as final and delegates the processing to protected abstract void doInTransactionWithoutResult; when this method completes, the TransactionCallbackWithouResult.doInTransaction returns null.

Even though you can use programmatic transaction support (and the TransactionTemplate class greatly simplifies this), it is still a lot of work. If you cast your mind back to the AOP chapters (Chapters 5 and 6), you can see that transaction management is a good application of around advices. In the next section, we will take a look at the different options for declarative transaction management.

The TransactionProxyFactoryBean has been with us since Spring 1.0, and Spring 2.5 still supports its functions, even though the implementation has changed substantially. In short, the factory bean creates a JDK proxy to the target bean and intercepts every method call. It decides how to handle any transactional code depending on additional configuration. Let's jump straight into an example; Listing 16-17 shows how we can create the proxy bean. We are going to use the TransactionProxyFactoryBean to declaratively specify transactional behavior of your beans.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       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.xsd">

    <bean id="bankService"
          class="org.springframework.transaction.interceptor.

                        TransactionProxyFactoryBean">
        <property name="target">
            <bean class="com.apress.prospring2.ch16.services.DefaultBankService">
                <property name="accountDao" ref="accountDao"/>
            </bean>
        </property>

<property name="transactionAttributes">
            <value>
                *=PROPAGATION_REQUIRED
            </value>
        </property>
        <property name="transactionManager" ref="transactionManager"/>
    </bean>
</beans>

This configuration is not pretty, but it does an excellent job: the code in the DefaultBankService is not aware that the transfer method now runs in a transaction. Even though the TransactionProxyFactoryBean is the Spring 1.x-style of declarative transaction management, we will describe it in more detail in case you encounter it in existing Spring applications.

The TransactionProxyFactoryBean creates a JDK, which intercepts calls to all methods. For any method whose name appears as the key in the transactionProperties, it starts a transaction with the specified propagation level. In the example in Listing 16-17, all methods will be transactional, and the proxy will call code equivalent to that shown in Listing 16-18.

TransactionDefinition transactionDefinition = new TransactionDefinition() {
    public int getPropagationBehavior() {
        return TransactionDefinition.PROPAGATION_REQUIRED;
    }

    public int getIsolationLevel() {
        return TransactionDefinition.ISOLATION_DEFAULT;
    }

    public int getTimeout() {
        return TransactionDefinition.TIMEOUT_DEFAULT;
    }

    public boolean isReadOnly() {
        return false;
    }

    public String getName() {
        return "Transaction-1";
    }
};
TransactionStatus transactionStatus =
           this.transactionManager.getTransaction(transactionDefinition);
try {
    target.invoke(arguments);
} catch (Throwable t) {
    if (t ( allowedExceptions)
       this.transactionManager.commit(transactionStatus);
    else if (t ( disallowedExceptions || disallowedExceptions.isEmpty())
       this.transactionManager.rollback(transactionStatus);
    throw t;
}

You can see that the proxy handles the transaction in exactly the same way as in Listing 16-14. However, the code is slightly more complex because the TransactionProxyFactoryBean gives you finer control over the transaction-handling code than the TransactionTemplate or our programmatic code.

First, you may notice that the proxy sets all properties of the TransactionDefinition instance and that the proxy will commit the transaction even if the target method throws an exception, as long as that exception is in the set of allowed exceptions. You can control all aspects of transaction handling in the transactionAttributes property entry. Listing 16-19 shows the detailed syntax of the property entry.

expr ::=
   method = propagation
       isolation? read-only? timeout? allowedExceptions? disallowedExceptions?

method ::= IDENT*;
propagation ::= 'PROPAGATION_' IDENT;
isolation ::= 'ISOLATION_' IDENT;
read-only ::= 'readOnly';
timeout ::= 'TIMEOUT_' INT;
allowedExceptions ::= '+' exceptions+;
disallowedExceptions ::= '-' exceptions+;
exceptions ::= exception (, exception)*;
exception ::= IDENT;

IDENT ::= java identifier pattern;
IDENT* ::= java identifier pattern + * (wildcard);
INT ::= integer pattern;

At the least, the expression must specify the method name and propagation, for example transfer=PROPAGATION_REQUIRED. The most complex expression can look like this:

transfer=PROPAGATION_REQUIRED, ISOLATION_SERIALIZABLE, readOnly, 

timeout_500, +MyBenignException, +AnotherAllowedException, -BadException

You may notice that the TransactionProxyFactoryBean has other properties, for example exposeProxy and pointcut; their names sound like some of the terms we explored in the AOP chapters. In fact, Spring 2.5 uses AOP in the implementation of the TransactionProxyFactoryBean. Moreover, AOP transaction handling is the preferred declarative transaction management approach in Spring 2.5.

If you recall, in Chapter 6, we discussed the impact of proxying on the advised objects. The transactional proxies are no different from any other proxies. Let's change our DefaultBankService to perform additional balance checking before calling the doTransfer method (see Listing 16-20).

public class DefaultBankService extends BankServiceSupport
        implements BankService {

    public void transfer(AccountIdentity from, AccountIdentity to,
                         BigDecimal amount) {
        if (getBalance(to).compareTo(new BigDecimal("1000000000")) > 0) {
            throw new RuntimeException("Billionaires do not need more money!");
        }
        doTransfer(from, to, amount);
    }

public BigDecimal getBalance(AccountIdentity accountIdentity) {
        return doGetBalance(accountIdentity);
    }
}

If we run this application, the proxy will intercept the call to the transfer method and start a new transaction, but the getBalance(BigDecimal) method will not start a new transaction, because the getBalance(BigDecimal) method is being executed not on the proxy but on the proxy target.

In this simple example, the fact that the getBalance method is not being executed in its own transaction is not a problem; in fact, it is the desired behavior. There can be situations where nested transactions (or the lack of them) can cause problems. In Chapter 11, we explored the implications of nested transactions on Hibernate sessions and the problems transaction nesting may cause with lazy loading.

If you do require nested transactional behavior, you must take the approach we explored in Chapter 6: use ((BankService)AopContext.currentProxy()).getBalance(to), which binds the implementation to Spring AOP. Alternatively, you can use Spring AOP transaction management with load-time weaving.

You can use annotations with AOP automatic proxying to introduce transactional behavior to existing beans. Let's begin with Listing 16-21, which shows the DeclarativeTxBankService class.

public class DeclarativeTxBankService
        extends BankServiceSupport implements BankService{

    @Transactional
    public void transfer(final AccountIdentity from,
                         final AccountIdentity to,
                         final BigDecimal amount) {
        doTransfer(from, to, amount);
    }

    @Transactional
    public BigDecimal getBalance(AccountIdentity accountIdentity) {
        return doGetBalance(accountIdentity);
    }

}

Notice the @Transactional attribute; to allow Spring's transaction management infrastructure to use this attribute to create the appropriate pointcuts and advice, we need to use AOP's automatic proxying and transaction annotation-driven support. Listing 16-22 shows the XML configuration for annotation-based transaction management.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       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.xsd
            http://www.springframework.org/schema/tx
            http://www.springframework.org/schema/tx/spring-tx.xsd
            http://www.springframework.org/schema/aop
            http://www.springframework.org/schema/aop/spring-aop.xsd">

    <bean id="bankService"
          class="com.apress.prospring2.ch16.services.DefaultBankService">
        <property name="accountDao" ref="accountDao"/>
    </bean>

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

</beans>

This XML configuration file shows the standard bankService bean declaration, followed by the <tx:annotation-driven /> and <aop:aspectj-autoproxy /> tags. The <tx:annotation-driven /> tag creates the appropriate transaction management aspects using the @Transactional annotation. The <aop:aspectj-autoproxy /> tag then advises the matching beans.

Exploring the tx:annotation-driven Tag

The <tx:annotation-driven /> tag is at the core of the annotation-driven transaction management support. Table 16-3 lists all attributes of the <tx:annotation-driven /> tag.

Exploring the @Transactional Annotation

The @Transactional annotation allows you to control all aspects of the transaction definition the advice is going to create. Just as with the transactionAttributes property expression, you can specify the propagation, isolation level, timeout, and allowed and disallowed exceptions. Table 16-4 lists all attributes of the @Transactional annotation.

Annotation-Based Transaction Management Summary

Using the @Transactional annotation is an easy way to declare a method transactional. The advantage is that you can immediately see that the method is transactional, because it has the annotation. The disadvantage is that you have to repeat the @Transactional annotation for every transactional method. This is not a problem if you are happy with the default transaction attributes but quickly becomes a clumsy copy-and-paste affair when you are setting additional transaction attributes. An alternative is to annotate the class with the @Transactional annotation. This would make all methods in the class transactional. The problem with this approach is that all methods, even simple getters and setters, would run in a transaction, even though there is absolutely no need for that. The XML AOP transaction management handles such situations much better.

XML AOP declarative transaction management is the preferred approach in Spring 2.5. Spring comes with the <tx:advice /> tag, which creates a transaction-handling advice. All we need do to get us started is to create a pointcut that matches all methods we wish to make transactional and reference the transactional advice. Listing 16-23 shows an XML configuration that uses XML AOP transaction management.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       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.xsd
            http://www.springframework.org/schema/tx
            http://www.springframework.org/schema/tx/spring-tx.xsd
            http://www.springframework.org/schema/aop
            http://www.springframework.org/schema/aop/spring-aop.xsd">


    <bean id="bankService"
          class="com.apress.prospring2.ch16.services.DefaultBankService">
        <property name="accountDao" ref="accountDao"/>
    </bean>

    <aop:config>
        <aop:pointcut id="allServiceMethods"
                      expression="execution(* 

                              com.apress.prospring2.ch16.services.*.*(..))"/>

        <aop:advisor advice-ref="defaultTransactionAdvice"
                     pointcut-ref="allServiceMethods"/>
    </aop:config>

    <tx:advice id="defaultTransactionAdvice"
            transaction-manager="transactionManager"/>

</beans>

This configuration file may seem much more complex than the TransactionProxyFactoryBean in Listing 16-17, so let's examine it in more detail. First, we used the defaultTransactionAdvice, which can specify the actions the proxy needs to perform when it intercepts the method call. If we leave the tag empty, it will assume that all methods should be transactional, that the propagation level is PROPAGATION_DEFAULT, that the isolation is ISOLATION_DEFAULT, that the timeout is TIMEOUT_DEFAULT, that the read-only property is false, and that all runtime exceptions cause rollbacks. To use the advice, we create the allServiceMethods pointcut for all methods in all classes in the com.apress.prospring2.ch16.services package. Finally, we create an aspect using the defaultTransactionAdvice for all methods matched by the allServiceMethods pointcut.

Before we take a more detailed look at the <tx:advice /> tag, you may be wondering why this approach is preferred, because the TransactionProxyFactoryBean seems a lot easier. But the TransactionProxyFactoryBean is easier only if you have very few transactional beans. When you get to a point where you have several beans whose methods you want to declare transactional, you would have to create a TransactionProxyFactoryBean for every bean; moreover, you would have to repeat the transactionAttributes declaration in the proxy factory beans. The XML configuration in Listing 16-23 will apply the same transaction management to any number of new beans we create in the services package; all we have to do is to create a plain bean definition for every new bean. We won't have to configure anything else to have the transactional advice applied to all new service beans.

Exploring the tx:advice Tag

As you saw in Listing 16-23, you need to set the id and transaction-manager attributes in the <tx:advice /> tag. The id is the identity of the advice bean, and the transaction-manager must reference a PlatformTransactionManager bean.

Beyond these two attributes, you can customize the behavior of the advice the <tx:advice /> tag creates by using the <tx:attributes /> tag. This allows you to configure everything that the transactionAttributes properties expression allowed you to do but in a more structured way. Let's take a look at Listing 16-24, which shows a more complicated <tx:advice /> tag.

<tx:advice id="defaultTransactionAdvice"
    transaction-manager="transactionManager">
    <tx:attributes>
        <tx:method
                name="*"
                isolation="READ_COMMITTED"
                propagation="REQUIRED"
                timeout="100"/>
        <tx:method
                name="get*"
                read-only="true"/>
    </tx:attributes>
</tx:advice>

We have transaction advice that will start a transaction using the PROPAGATION_REQUIRED propagation, READ_COMMITTED isolation level, and a 100-second timeout for all methods unless the method's name begins with get; in which case, the transaction definition will include PROPAGATION_DEFAULT, ISOLATION_DEFAULT, TIMEOUT_DEFAULT, and the read-only property will be set to true. In both cases, any runtime exception will cause a rollback.

As you can see, the <tx:attributes /> tag allows you to create the transactionAttributes property expression in a more concise way; in addition, most IDEs will offer code completion (see Figure 16-2).

Figure 16.2. <tx:attributes> code completion in IntelliJ IDEA

The <tx:attributes /> tag allows only <tx:method /> tags to appear as its children. To complete the description of the <tx:attributes /> tag, Table 16-5 details the attributes of the <tx:method /> tag.

XML AOP Summary

Unlike annotation-based AOP transaction management, when you use XML AOP transaction management, the code in your beans does not reflect any transactional behavior at all. The XML configuration easily offsets this disadvantage with the fact that you do not need to repeat any details of the transaction management configuration. In addition, you can refer to pointcuts you use in your application's AOP configuration to allow the most effective code reuse.

We usually use the annotation-based approach during the implementation of the application, but in the production environment, we always try to use XML configuration only.