Coordination of access to one-phase commit and two-phase commit capable resources in the same transaction

Last participant support enables the use of a single one-phase commit capable resource with any number of two-phase commit capable resources in the same global transaction. We can have multiple interactions that involve the one-phase commit resource in the same transaction, but only one such resource can be involved.

At transaction commit, the two-phase commit resources are prepared first using the two-phase commit protocol, and if this is successful, the one-phase commit-resource is then called to commit. The two-phase commit resources are then committed or rolled back, depending on the response of the one-phase commit resource.

If the global transaction is distributed across multiple application servers that are all running at WebSphere Application Server version 6.1 or later, we can exploit last participant support to coordinate a one-phase commit capable resource and any number of two-phase commit capable resources in the same transaction, in a limited number of scenarios.

• The main scenario is where the one-phase commit resource provider is accessed in the application server process (the "transaction root" server) in which the transaction is started.

  In this scenario, last participant support can coordinate a one-phase commit capable resource and any number of two-phase commit capable resources in the same transaction.

• If the one-phase commit resource provider is accessed in a different application server (a "transaction subordinate" server) from the one in which the transaction was started; for example, as a result of a transactional invocation on a remote EJB interface where the EJB implementation accesses a one-phase commit resource provider.

  In this scenario, the transaction typically cannot be committed. To be able to commit (as part of a global transaction) a one-phase commit resource enlisted on a transaction subordinate server, the transaction service must delegate coordination responsibility from the transaction root to the subordinate server. This occurs only if no other resources were registered with the transaction root server.

Last participant support introduces an increased risk of an heuristic outcome to the transaction. That is, the transaction manager cannot be sure that all resources were completed in the same direction (either committed or rolled back). For this reason, to enable an application to coordinate access to one-phase and two-phase commit capable resources in the same transaction, you configure the application to accept the heuristic hazard, that is, accept the increased risk of an heuristic outcome.

An heuristic outcome occurs if the transaction service (JTS) receives no response from the commit one-phase flow on the one-phase commit resource. In this situation, the transaction service cannot determine whether changes for the one-phase commit resource were committed or rolled back, so cannot drive reliably the correct outcome of the global transaction on the other two-phase commit resources.

We can configure the transaction service for an application server to accept the heuristic hazard, or we can configure applications individually to accept the heuristic hazard. We can configure applications individually either when they are assembled, or after they are deployed.

We can configure the transaction service for an application server to indicate whether or not to log that it is about to commit the one-phase commit resource. This does not reduce the heuristic hazard, but ensures that any failure, and subsequent recovery, of the application server during the one-phase commit phase occurs with knowledge of whether or not the one-phase commit resource was asked to commit:

• If the one-phase commit resource was asked to commit, a heuristic outcome is reported to the activity log.

• If the one-phase commit resource was not asked to commit, then the transaction is rolled back consistently.

Transaction exceptions that involve both one-phase and two-phase commit resources

The exceptions that can be thrown by transactions that involve one-phase and two-phase commit resources are the same as those that can be thrown by transactions involving only two-phase commit resources.

The exceptions that can occur are listed in the application programming interface (API) reference information in the WAS information center.

Subtopics

• Last Participant Support: Resources for learning
  Use the links in this topic to find relevant supplemental information about Last Participant Support. The information resides on IBM and non-IBM Internet sites, whose sponsors control the technical accuracy of the information.

Additional APIs Concept topic