From the database, you will see that the new contact is persisted to both schemas of the database,
respectively.
Now let's see how the rollback works. As shown in the code in Listing 13-25, instead of calling
emB.persist(), we just throw an exception. Listing 13-27 shows the code snippet.
Listing 13-27. Testing JTA Transaction Rollback
//emB.persist(contactB);
throw new JpaSystemException(new PersistenceException());
To test the rollback scenario, delete the new records inserted by the previous example from the two
MySQL databases first (i.e. , the contact record with FIRST_NAME Jta and LAST_NAME Manager). Running the
program again will produce the following results:
Hibernate: insert into contact (BIRTH_DATE, FIRST_NAME, LAST_NAME, VERSION) values (?, ?, ?,
?)
INFO [atomikos] - <afterCompletion ( STATUS_ROLLEDBACK ) called on Synchronization:
org.hibernate.transaction.synchronization.HibernateSynchronizationImpl@45c81ac0>
INFO [atomikos] - <rollback() done of transaction 192.168.11.8.tm0000100002>
Exception in thread "main" org.springframework.orm.jpa.JpaSystemException: nested exception is
javax.persistence.PersistenceException
...
Caused by: javax.persistence.PersistenceException
As shown in the previous output, the first contact is persisted (note the insert statement).
However, when saving to the second datasource, because an exception is thrown, Atomikos will roll
back the entire transaction. You can take a look at the schema prospring3_ch13a to check that the new
contact was not saved.
Considerations on Using JTA Transaction Manager
Whether to use JTA for global transaction management is under hot debate. For example, the Spring
development team generally does not recommend using JTA for global transactions, and SpringSource's
Dr. David Syer has posted an article describing seven ways to implement distributed transactions, four of
As a general principle, when your application is deployed to a full-blown JEE application server,
there is no point not using JTA because all the vendors of the popular JEE application servers have
optimized their JTA implementation for their platforms. That's one major feature that you are paying
for.
For stand-alone or web container deployment, let the application requirements drive your decision
and perform load testing as early as possible to verify that the performance is not being impacted by
using JTA.
One piece of good news is that Spring works seamlessly with both local and global transactions in
most major web and JEE containers, so code modification is generally not required when you switch
from one transaction management strategy to another.
In case you decide to use JTA within your application, make sure you use Spring's
JtaTransactionManager. There is another excellent article from Spring's team discussing using
Search WWH :
