8.5. Process Structuring

Independent Transaction Managers

Now that we have studied two-phase commit from a single transaction’s viewpoint, it is time to see how a system can manage two-phase commit on behalf of many transactions and resource managers. The usual approach is to have one module, the transaction manager, be responsible for running the two-phase commit protocol, performing both the coordinator and participant functions for a group of transactions. The transaction manager usually is packaged with another product, such as the operating system (as in Microsoft Windows and HP’s OpenVMS) or transactional middleware (as in IBM’s Websphere or Oracle’s WebLogic).

One possibility is to have the transaction manager be part of the database system. This works fine for transactions that access multiple copies of one particular database system. But it generally does not work with other database systems, because each database system uses its own two-phase commit protocol, with its own message formats and optimizations. A different approach is needed for transactions to interoperate across different database systems.