Global transactions with JTA: For global transactions that need to span multiple
·
backend resources, we will show an example of how to configure and implement
global transactions in Spring using JTA.
Exploring the Spring Transaction Abstraction Layer
When developing your applications, no matter whether you choose to use Spring or not, you have to
make a fundamental choice when you use transactions about whether to use global or local
transactions. Local transactions are specific to a single transactional resource (a JDBC connection, for
example), whereas global transactions are managed by the container and can span multiple
transactional resources.
Transaction Types
Local transactions are easy to manage, and if all operations in your application need to interact with just
one transactional resource (such as a JDBC transaction), using local transactions will be sufficient.
However, if you are not using an application framework such as Spring, you have a lot of transaction
management code to write, and if in the future the scope of the transaction needs to be extended across
multiple transactional resources, you have to drop the local transaction management code and rewrite it
to use global transactions.
In the Java world, global transactions were implemented with the Java Transaction API (JTA). In this
scenario, a JTA-compatible transaction manager connects to multiple transactional resources via
respective resource managers, which are capable of communicating with the transaction manager over
the XA protocol (an open standard defining distributed transactions), and the 2 Phase Commit (2PC)
mechanism was used to ensure that all backend datasources were updated or rolled back altogether. If
either of the backend resources fails, the entire transaction will roll back, and hence the updates to other
resources will be rolled back too.
Figure 13-1 shows a high-level view of global transactions with JTA.
Figure 13-1. Overview of global transactions with JTA
Search WWH :
