| 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.
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
- Client invokes a method on EJB1, which starts a global transaction T1.
- EJB1 invokes a method on EJB2 within the context of transaction T1. T1 is propogated across EJB2.
- EJB1 invokes a method on EJB3, which requires a new transaction be started. Transaction T1 is suspended and transaction T2 is started.
- The method on EJB3 executes and then returns back to EJB2.
- 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.
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.
In the next lesson you will be introduced to the Java packages that underlie the transaction system.