Two-phase commit (also known as XA, which is a protocol for two-phase commit) protocol is a method for coordinating J2EE global transactions. In other words, when data is modified across multiple resources, the XA protocol ensures that transactional updates are committed in or rolled back out of all the participating resources, reverting to the state prior to the start of the transaction. Thus, either all the participating resources are updated or none of them are updated. The resource managers have to be XA-enabled to be able to participate in a 2-PC transaction. Since coordination of several resource managers is necessary, the WebSphere Application Server (WAS) uses a transaction manager to coordinate the transaction.
The transaction manager is external to any of the resource managers and is provided by the application server. The transaction manager uses the javax.transaction.xa.XAResource interface to coordinate the 2-PC process. The communication steps between the transaction manager and the resource managers are as follows. Steps 3 and 4 below are the two phases of the commit process.
1. Start- The transaction manager enlists the resource as part of the transaction. This tells the resource manager to record all future work as part of the transaction.
2. End -The transaction manager informs the resource manager that no more transaction work is coming its way for this transaction. This is a signal for the resource manager to stop recording. At this point, the resource manager holds the recorded work in a bucket associated with the current transaction ID and waits for further instruction from the transaction manager.
3. Prepare (Phase 1) -The transaction manager asks all resource managers to prepare to commit their work. At this moment all the resource managers vote on the outcome of the transaction. If they all respond affirmatively, the transaction is committed. If any resource manager responds negatively, the whole transaction rolls back.
4. Commit (Phase 2) -The transaction manager asks all resource managers to either commit or roll back the work done on behalf of the transaction, based on the responses in the prepare phase.
Considerations - XA-Enabled Resources
As a general guideline use XA-enabled resources if:
• There may be more than one participant in a transaction (for example, two JDBC databases or a database and a JMS connection). This allows the container to perform any appropriate optimizations if there is only one participant, but to handle XA correctly if there are two or more participants.
• An EJB needs to access another EJB deployed in a different EJB container, and it is desirable to have both EJBs participate in a single transaction, then both containers should use XA resource managers. The only way to tie the two EJBs together into a single transaction is to use XA resources in both EJBs. This is an example of a distributed transaction; and requires the use of XA resources.
It can be assumed that the container will appropriately manage local vs. global transactions based on the number of participants and that it will perform automatic optimizations.
Performance
It is important to note that using XA-enabled resources degrades performance. The resource access
is between 18-27% slower using an XA resource manager than a non-XA resource manager. However, this is for basic operations; in a real application the cost would be a smaller percentage of the total as compared to the other operations. This difference is enough to be concerned about in performance-critical situations, but not large enough to prohibit the use of XA when it is necessary.
Last Participant Support(LPS)
WebSphere's Last Participant Support (LPS) can be used if the given unit of work needs to access a
resource that does not support 2-PC but can participate in a WebSphere-managed transaction. This is
an advanced capability of the transaction manager to coordinate global transactions involving a number of two-phase commit-capable resource managers and a single one-phase commit-capable resource manager. When a global transaction involving this mix of resources is about to be committed, the transaction manager uses the 2-PC protocol to prepare all two-phase commit-capable resources. If this is successful, the one-phase commit (1-PC) resource is asked to commit the transaction. Depending on the outcome of the one-phase resource commit operation, the two-phase commit resources are then committed or rolled back.
Keep in mind that LPS is not a real transaction and only allows the application to get as close to 2-PC as possible. LPS introduces a hazard of a mixed commit result because 1-PC resources can't completely participate in the 2- PC protocol. For example, if the transaction manager doesn't get a response from the 1-PC resource, it has no way of knowing the status. Therefore, the transaction manager cannot reliably determine the correct outcome of the global transaction on other 2-PC resources. In this case, manual intervention will be required to resolve the state of the data in the 1-PC resource.
No comments:
Post a Comment