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.
12.5.1
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
follows:
public interface TransactionConfig {
public void initialize(Properties props)
throws SQLException, TransactionException;
public Transaction newTransaction(int
transactionIsolation)
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:
