Distributed Transactions   «Prev 
122

Java Transaction Service - JTS and JTA

The peer model

In this architectural model, independent processes collaborate to perform some task in a coordinated fashion. The peer approach is common in situations where either a lot of computing power is needed to perform an intense calculation or where independent systems need to guarantee that synchronized states are maintained. Any system that is transactional makes use of this model for at least part of its functionality.
The peer model treats all processes as equals, although it often requires one of them to act as a group coordinator. An example of a peer processing situation in scientific applications is gene sequencing; a business processing example is executing a distributed purchasing transaction. In these situations, each process calculates part of some result and contributes it to the whole. For example, as a customer places an order, a pricing process calculates a specific customer�s price for each item on an order and adds those prices to the order information. J2EE supports peer processing via the Java Transaction Architecture (JTA) API. Using this API, your components can interact in a scoped, coordinated way with each other and with external systems. JTA is one of the many J2EE APIs available to you, and transactional support is one of the key features of any J2EE EJB container.


JTS and JTA
JTS and JTA

1. Transaction Manager compartment

The Transaction Manager (TM) coordinates all activities on behalf of all interested parties. The transaction manager cooperates with all the other transaction managers that are within the scope of the transaction.

2. Application compartment

The application, such as an EJB client or an EJB itself, controls a transaction it starts. The interface between the client and the transaction manager is the javax.transaction.UserTransaction object.

3. Application Server Compartment

The Application Server creates and controls transactions in a similar way to the client. An EJB container represents the application server in the EJB universe.

4. Resource Manager

Any resources that wish to take part in a transaction must have a specific resource manager. The resource manager registers itself with the transaction manager and then performs the commit or the rollback when requested by the transaction manager. The resource manager also understands two-phase commits. The resource manager is typically the driver to a persistent data store of some kind.

5. Transaction Service Implementation

The low-level transaction service provides distributed transaction capabilities and takes care of the propagating transactions from upstream or to downstream objects and resources. It is bundled into the EJB server.