The transaction model

This section briefly reviews the concepts from which the IBM WebSphere InterChange Server transactional model are derived. If you are familiar with databases and transactional processing, skip to the next section.

A transaction is a set of related and interdependent steps that form a logical unit of work. Grouping the steps into a transaction ensures that the set of steps are treated as an atomic unit: either the entire set of steps succeeds, or the entire set of steps fails.

Figure 38 illustrates a database transaction that contains two updates, update 1 and update 2.

Figure 38. A database transaction


As a transaction is executing, it locks the part of the database that it is modifying, making the data unavailable for modifications by other transactions. Isolation of data from outside interference is one of the defining qualities of transactions.

If the transaction's operations succeed, the transaction completes by writing changes to disk in a commit operation. A commit operation releases the transaction's locks, making the updated data available to other transactions.

If an error occurs partway through execution, making it impossible for the entire transaction to succeed, the entire transaction fails. Rather than leave partial results in the database, the transaction backs out the changes that it has already made, leaving the database with the values that it had before the transaction started. The back-out process is called rollback.

Another type of database transaction, two-phase commit, is adapted for distributed use across multiple databases. Two-phase commit uses a transaction monitor to coordinate concurrent updates. The transaction monitor first checks that all databases can make the desired change. Even if all can make the change, they must wait for the transaction monitor's signal before doing so. If all cannot make the change, none do.

Every transaction must maintain data consistency in its database, but the two-phase commit protocol extends the scope of this requirement beyond individual databases. A common example is a funds transfer, in which the transaction monitor ensures that the funds debited from one account are credited in the other account or that neither account is modified.

Copyright IBM Corp. 1997, 2004