Java Reference
In-Depth Information
■
TRANSACTION_READ_UNCOMMITTED
■
TRANSACTION_READ_COMMITTED
■
TRANSACTION_REPEATABLE_READ
■
TRANSACTION_SERIALIZABLE
■
TRANSACTION_NONE
Each of these is documented in the
JDBC
Connection
API
, and you can learn more
in chapter 7. The important thing to note here is that if your transaction manager
implementation does not support one or more of these, you should be sure to
throw an exception to let the developer know. Otherwise, there could be unex-
pected consequences that are difficult for your users to debug.
The next pair of methods are
getDataSource()
and
setDataSource()
. These
methods describe a
JavaBeans
property for the
DataSource
associated with this
TransactionConfig
instance. Usually you won't have to do anything special with
the
DataSource
, but it is provided here so that you can decorate it with additional
behavior if you need to. Many transaction manager implementations wrap the
DataSource
and the
Connection
objects it provides, to add transaction related
functionality to each of them.
The final pair of methods makes up another
JavaBeans
property that allows
the framework to configure a maximum number of concurrent transactions sup-
ported. Your implementation may or may not be configurable, but it is important
to ensure that you throw an appropriate exception if the number set is too high
for your system to handle.
12.5.2
Understanding the Transaction interface
Recall the factory method called
newTransaction()
on the
TransactionConfig
class discussed in the previous section. The return value of that method is a
Transaction
instance. The
Transaction
interface describes the behavior neces-
sary to support transactions within the
iBATIS
framework. It's a pretty typical set of
functionality, which will be familiar to anyone who has worked with transactions
before. The
Transaction
interface looks like this:
public interface Transaction {
public void commit() throws SQLException,
TransactionException;
public void rollback() throws SQLException,
TransactionException;
