Commit priority for transactional resources

We can specify the order in which transactional resources are processed during two-phase commit processing.

If we control the order in which transactional resources are processed during two-phase commit processing, there are two main benefits:

• One-phase commit optimization occurs more often.

• Potential problems caused by transaction isolation are resolved.

To control the order in which transactional resources are processed during two-phase commit processing, specified the commit priority of a resource by setting the commit priority attribute on a resource reference. The larger the commit priority, the earlier the resource is processed. For example, if a resource has a commit priority of 10, it is processed before a resource with a commit priority of 1. The commit priority value is of type int and can be between -2147483648 and 2147483647.

If we do not specify a commit priority value, a default value of zero is assigned to the resource and is used when ordering resources at run time. If two or more resources are configured with the same priority, including the default priority, they are processed in an unspecified order with respect to each other.

We can specify the commit priority attribute on a resource reference by using Rational Application Developer tools. For detailed information, see the Rational Application Developer information center. The application component must have a deployment descriptor; we cannot specify this attribute if annotation has been used.

One-phase commit optimization

In a transaction with a two-phase commit, if every resource except the last one enlisted in the transaction votes read-only, indicating that those resources are not interested in the outcome of the transaction, a one-phase commit can occur. This means that the transaction service does not have to store resource and transaction information that it would need to roll back a two-phase commit, and therefore performance is improved.

We can control the order in which transactional resources are processed during two-phase commit, so we can process the resources that are most likely to vote read-only first. Therefore, you increase the chance that a one-phase commit might occur.

Typically, for a given transactional resource, you know the work performed at run time, so if we can control the order in which the resources in a transaction are processed, we can increase the likelihood of a one-phase commit optimization occurring.

config: If we use the MQ resource adapter with an activation specification, the application server is not able to optimize RRS transactions to use one-phase commit. Use listener ports if you require this functionality.

Transaction isolation

When resources are involved in a global transaction, updates that are made as part of a transaction are not visible outside the transaction until the transaction commits, that is, those resources are isolated. This isolation can cause problems with other application components that act on the updates after they are committed. For example, further processing can fail, or can fail intermittently, because updates are order and time dependent. This problem does not occur with service integration bus messaging work in WebSphere Application Server, but can be a problem for other messaging providers, for example WebSphere MQ.

If we specify the order in which transactional resources are committed, problems caused by isolation are resolved for all transactional systems, not just messaging providers and service integration bus in particular.

The following example describes how problems might occur when we cannot specify the order in which transactional resources are committed. An application updates a row in a database table, then sends a JMS message that triggers additional processing of the row. Both of these actions are performed in the same global transaction, so they are isolated until their respective resources are committed. If the update to the row is committed before the message is sent, the processing that is triggered by the message can access the updated row and process it. If the action to send the message is committed first, this action might trigger the additional processing of the row before the database has committed the update to the row. In this situation, the updated row is still isolated and is not visible, so the additional processing of the row fails.

This problem can be more complicated because it is ordering and timing dependent. If the database is committed first, the problem does not occur. If the action to send the message is committed first, the problem might occur, but it depends whether the database work is committed before the message triggers the further processing of the row. Therefore, the problem can be intermittent, so it is harder to identify its cause.

Restrictions with earlier versions of WAS

If we specify the commit priority of a resource, that is, specify any value other than the default value 0, the commit priority is added to the partner log in a recoverable unit section. This section in the log file is recognized in WAS v7 or later, but not in earlier versions of the application server.

If an application uses the commit priority attribute, we cannot install that application into a mixed-version cluster where one or more servers in the cluster are at versions of WAS that are earlier than Version 7.0.

Also, if an application that uses the commit priority attribute is installed in a cluster, we cannot subsequently add a server to that cluster if the server is at a version of WAS that is earlier than Version 7.0.

For general information about different versions of the product, see the topic "Overview of migration, coexistence, and interoperability".