Distributed Transactions   «Prev  Next»

Lesson 4 Management of distributed transactions
Objective Describe how distributed transactions are managed.

Management of Distributed Transactions

Global Transaction Context

Transactions span multiple components. In the previous example, both bank accounts and the EJB that is transferring the money from checking to savings cooperate in a single transaction.
This is known as a global transaction
You can think of this global transaction as an umbrella that "covers" all the activities and components within the transaction.

Global Transaction

A transaction that is propagated by the transaction manager to all the resources that are involved in the processing of that transaction

Global Transactions are managed by the Server

The server is responsible for managing global transactions. When a server receives a transaction, it is propagated to other servers and resources that are invoked by the bean instance within the context of the transaction.

Suspending Transactions

The server may be asked by the bean instance or the container to start a new transaction. What if the server has an existing transaction context? In this case, the server will suspend the existing transaction before starting the next one. When the new transaction ends, the server will restart the original transaction. One of the rules of JTS is that transactions cannot be nested only suspended. This is illustrated in the following SlideShow.

Suspending EJB Transactions

1) Client invokes a method on EJB1, which starts a global transaction T1.
1) Client invokes a method on EJB1, which starts a global transaction T1.

2) EJB1 invokes a method on EJB2 within the context of transaction T1.
2) EJB1 invokes a method on EJB2 within the context of transaction T1. T1 is propogated across EJB2.

3) EJB1 invokes a method on EJB3, which requires a new transaction be started
3) EJB1 invokes a method on EJB3, which requires a new transaction be started. Transaction T1 is suspended and transaction T2 is started.


4) The method on EJB3 executes and then returns back to EJB2
4) The method on EJB3 executes and then returns back to EJB2. Transaction T2 is completed (either committed or rolled back) and transaction T1 is restarted.

5) The method on EJB1 completes and transaction T1 is committed or rolled back. Control is returned back to the client.
5) The method on EJB1 completes and transaction T1 is committed or rolled back. Control is returned back to the client.

  1. Client invokes a method on EJB1, which starts a global transaction T1.
  2. EJB1 invokes a method on EJB2 within the context of transaction T1. T1 is propogated across EJB2.
  3. EJB1 invokes a method on EJB3, which requires a new transaction be started. Transaction T1 is suspended and transaction T2 is started.
  4. The method on EJB3 executes and then returns back to EJB2.
  5. The method on EJB1 completes and transaction T1 is committed or rolled back

The EJBs that are invoked within the context of a transaction may be in the same or different containers in the same or different servers. The mechanism that makes this work involves sending the transaction context with each message that passes from clients to EJBs. This is transparent to the bean instance. It implies that the stubs, skeletons, and drivers are all transaction-aware.


Two-phase Commits

In a transaction, there may be multiple resources whose state will change permanently when a transaction is committed. These resources may be on the same or different machines. There is a technique called a two-phase commit, that is used to commit or rollback a single transaction across multiple resources in different environments. It originally evolved in the RDBMS world. The two-phase commit guarantees that multiple remote resources are updated automatically.
For more information on transaction processing in general, and two-phase commits in particular, refer to the Principles of Transaction Processing.

Two-phase commit

A two-phase commit is a mechanism by which the committing of a transaction that invloves multiple recoverable resources guarantees atomicity and an all or nothing result.
In the next lesson you will be introduced to the Java packages that underlie the transaction system.