Transaction levels

A collaboration's transaction level determines the mechanisms by which the system executes the scenarios in the collaboration.

A collaboration becomes transactional at the development phase, when its developer determines whether the collaboration requires transactional execution. If it does, the developer adds compensation steps to the scenarios in the template and specifies the collaboration's transaction level. Every collaboration has one of the following transaction levels:

During configuration, System Manager displays the minimum transaction level of a collaboration template, which a collaboration object made from that template inherits.

Other factors affect the transaction level at which a collaboration object actually executes, however. At configuration time, an administrator binds the collaboration object to connectors or collaboration objects, or to both. Each connector or collaboration object has a particular transaction level, and the collaboration must run at a level that all bindings support. For example, a connector's transaction level represents the level of support that it can provide, based on the capabilities of its application. The collaboration cannot run at a level that one of its connectors does not support.

None

A collaboration whose transaction level is None is not transactional. If an error occurs during the execution of the collaboration, an error message is logged.

Even if a collaboration template contains compensation steps, a collaboration object created from that template could execute at transaction level None. This could happen, for example, if the connector object's bindings do not support a higher transaction level. If that happens, the compensations are ignored.

Minimal Effort

A collaboration with Minimal Effort transaction level has compensations defined for its scenario's transactional steps. If an error occurs during execution of a scenario, the InterChange Server rolls back the scenario, executing the compensation for each transactional step that executed.

If the scenario called a different collaboration object to do a piece of work--that is, if the collaboration is part of a collaboration group--the scenario that executed in that collaboration also rolls back.

The Minimal Effort transaction level might be appropriate for a collaboration under the following conditions:

Best Effort

A collaboration that executes at the Best Effort transaction level uses isolation checking. The Best Effort transaction level is appropriate for collaborations that must guard against any data inconsistency.

When a collaboration executes with isolation checking:

Isolation checking provides good transactional semantics, but requires additional database access at the InterChange Server and more communication between connectors and the InterChange Server. This additional system work has an effect on performance. For this reason, you should weigh performance concerns against data consistency issues when choosing a transaction level.

However, even at Best Effort transaction level, a small window of vulnerability exists. Between the start of the isolation check and the time that the collaboration continues its operation, another transaction could modify the data. Nonetheless, Best Effort is the highest transaction level available with many combinations of applications, because few application APIs support the Stringent level.

Note:
The Best Effort transaction level is not supported for long-lived collaborations.

Stringent

Stringent transaction level provides the highest degree of isolation assurance, but it is available only with applications whose APIs allow client applications to do atomic test and set operations. The connector working with such an application locks data during the isolation check, thereby removing the possibility that another program could modify the scenario's data. Few applications currently provide this ability.

Copyright IBM Corp. 1997, 2004