Transactions - iBATIS in Action - page 155

<property name="DataSource"
value="java:comp/env/jdbc/someDataSource"/>
</dataSource>
</transactionManager>

Passive participation

Notice how in both cases the DataSource is retrieved from a JNDI context. This is a
practical requirement, since the connections you will need must be managed
within a global transaction manager scope. In the case of JTA , a UserTransaction
instance is also required from a JNDI context, so that it can actively participate. In
the case of the EXTERNAL transaction manager, it does not need the UserTrans-
action instance, as it assumes that some external system is managing the transac-
tion participation.

7.4.2 Starting, committing, and ending the transaction

Coding for a global transaction is exactly the same as coding for automatic or local
transactions. So you should still start, commit, and end the “inner transaction
scope.” You might ask why, considering the transaction is globally defined. There
are two reasons. First, it helps i BATIS manage other resources such as connections
to the database so that you don't unnecessarily keep requesting and returning con-
nections from the data source. Second, it allows you to switch back and forth
between local and global transactions without any code changes. Listing 7.5 shows
the same transaction as in the local example; and as you can see, it doesn't make a
difference to i BATIS whether you're using local or global transactions.

Listing 7.5 Global transaction

public void runStatementsUsingGlobalTransactions() {
SqlMapClient sqlMapClient =
SqlMapClientConfig.getSqlMapClient();
try {
sqlMapClient.startTransaction();
Person p =
(Person)sqlMapClient.queryForObject
("getPerson", new Integer(9));
p.setLastName("Smith");
sqlMapClient.update("updatePerson", p);

Department d =
(Department)sqlMapClient.queryForObject
("getDept", new Integer(3));
p.setDepartment(d);
sqlMapClient.update("updatePersonDept", p);
sqlMapClient.commitTransaction();