Java Reference
In-Depth Information
In most cases, one of the options in table 12.4 should work for you. However, if
your application server or transaction manager is nonstandard (or buggy), iBATIS
provides interfaces for you to build your own transaction management adapter:
TransactionConfig and Transaction . You will generally need to implement both
to have a complete implementation, unless your situation allows you to reuse one
of the Transaction classes from one of the other implementations.
Understanding the TransactionConfig interface
The TransactionConfig interface is a factory of sorts, but is mostly responsible for
configuring the transaction facilities for the implementation. The interface is as
public interface TransactionConfig {
public void initialize(Properties props)
throws SQLException, TransactionException;
public Transaction newTransaction(int
throws SQLException, TransactionException;
public int getMaximumConcurrentTransactions();
public void setMaximumConcurrentTransactions(int max);
public DataSource getDataSource();
public void setDataSource(DataSource ds);
The first method is initialize() . As we've seen with other parts of the framework
that can be extended, this method is used to configure the transaction facilities. It
takes a Properties instance as its only parameter, which can contain any number
of configuration options. For example, the JTA implementation requires a User-
Transaction instance that is retrieved from a JNDI tree. So one of the properties
passed to the JTA implementation is the JNDI path to the UserTransaction it needs.
Next is the newTransaction() method. This is a factory method for creating
new instances of transactions. It takes an int parameter (unfortunately; it should
be a type-safe enumeration) that describes the transaction isolation level within
which the transaction should behave. Available transaction isolation levels are
defined on the JDBC Connection class as constants as follows:
Search WWH ::

Custom Search