Global Transaction Management
Transactions are an important aspect based on which you can completely manage your applications stateful resources like databases and message queues etc. It also provides ACID guarantees for all operations performed within a single transaction. Transaction can be managed in your application by two ways:
- Locally (Local Transaction)
- Globally (Global Transaction)
We will now cover these two transaction management in some detail for your clear understanding and to tie things together before reading the “Summary” of this chapter.
Local transactions manage transactions on the resource itself like JDBC Connections, JMS Session etc. That’s the reason that local transactions as also known as native transaction. This is one of the best solutions if you have only single resource in your application. Its usually very fast and works in all environments without creating any issues. Having local transaction involving multiple resources would break the ACID behavior and it is no longer guaranteed. In the case of multiple resources, there needs to be someone who co-ordinates transaction across multiple resources. We will see how we can do that in next section.
Global transactions should be used when you want to allow for ACID guarantees with multiple transactional resources and that too all in a single transaction. Since it allows spanning multiple resources which can be distributed in all aspects, these transactions are also called distributed transactions.
If you want to have a set of operations in a single transaction spanning over multiple transactional resources, we will not be able to simply do a commit thinking that all the resources will do the necessary commits. It could be that due to some reasons, some resources failed while doing a commit. This doesn’t guarantee ACID properties and according to application criticality, this could be fatal. What it means is that, for committing global transactions having multiple resources in a single transaction, we need multiple coordinated steps.
Global transaction commit uses Two-Phase commit which provide multiple coordinated steps for committing such transactions.
A typical application topology consisting of multiple resources involved in single transaction using transaction managers can be represented as shown in Figure 18-11 below.
Figure 18-11. Topology of a typical application hosting multiple resources
Two-Phase Commit (2PC)
Two-Phase Commit (2PC) is completely driven by the associated transaction manager. The commit works in two phases as detailed below:
- Phase 1 (Commit-request Phase or Prepare Phase or Voting Phase) – a coordinator process attempts to prepare all the transaction’s participating resources to take the necessary steps for either committing or aborting the transaction and to vote, either “Yes”: commit or “No”: abort.
- Phase 2 (Commit Phase or Completion Phase) – based on voting done in Phase 1, the coordinator decides whether to commit or abort the transaction, and notifies the result to all the participating resources. Each resource then follows with the needed actions (commit or abort) with their local transactional resources.
For two-phase commit to work properly, it requires a common interface between transaction managers and the participating transactional resources without which they can’t communicate in a consistent manner and exchange appropriate statuses with each other.
The common standard to do this communication between participating resources and the transaction manager is called XA (eXtended Architecture), from the X/Open group.
Pictorially the two-phase commit can be represented as shown in Figure 18-12 below.
Figure 18-12. Two-phase commit in action
Page Visitors: 15356