The IBM WebSphere InterChange Server system provides several levels of transactional execution for collaborations. At the higher levels, the InterChange Server detects isolation violations. Isolation is the assurance that, while a transaction is executing, it has exclusive access to its data. Because the transaction's data does not change between operations inside the transaction, the effects of the transaction's logic are predictable.
In a database transaction or two-phase commit, database locks ensure isolation during execution of the transaction. In the IBM WebSphere InterChange Server environment, a transactional scenario cannot lock data between steps; each step causes an application transaction that, upon completion, releases its lock. Other programs can then view and modify the updated data.
A scenario might need to use the same piece of data more than once. For example, multiple action steps might update the same data. Furthermore, if a scenario fails and rolls back, a compensation step might revisit data that was set by previous actions, restoring it to the original value.
For data that a scenario uses more than once, the time period between the completion of an application transaction caused by one step and the start of an application transaction caused by another step is a window of vulnerability.
Figure 43 illustrates the window of vulnerability between two transactional steps that update the same business object.
Figure 43. Window of vulnerability
During the window of vulnerability, data isolation cannot be guaranteed. Other transactions might step in to change the state of the data between the scenario's visits, possibly causing errors in the scenario's results.
For some collaborations, isolation might not be relevant; for example, a collaboration might be the only program that modifies the data. However, if a scenario modifies data that other programs might also modify, isolation violations can be problematic.
The IBM WebSphere InterChange Server system provides isolation checking for collaborations that need to protect against isolation violations. If a collaboration runs at Best Effort or Stringent transaction level, the transaction service and connectors work together to determine whether data has been compromised between repeat visits. The next section describes the transaction levels and explains how isolation checking occurs at each level.