Java Reference
In-Depth Information
<property name="DataSource"
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.
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 =
try {
Person p =
("getPerson", new Integer(9));
sqlMapClient.update("updatePerson", p);
Department d =
("getDept", new Integer(3));
sqlMapClient.update("updatePersonDept", p);
Search WWH ::

Custom Search