Overview of Transaction Management in
The global and local transaction management
software modules, along with the concurrency control and recovery manager of a
DDBMS, collectively guarantee the ACID properties of transactions (see Chapter
21). We discuss distributed transaction management in this section and explore
concurrency control in Section 25.7.
As can be seen in Figure 25.5, an additional
component called the global transaction
manager is introduced for supporting distributed transactions. The site
where the transaction originated can
temporarily assume the role of global transaction manager and coordinate the
execution of database operations with transaction managers across multiple
sites. Transaction managers export their functionality as an interface to the
application programs. The operations exported by this interface are similar to
those covered in Section 21.2.1, namely BEGIN_TRANSACTION, READ or WRITE, END_TRANSACTION, COMMIT_TRANSACTION, and ROLLBACK (or
ABORT). The manager stores bookkeeping information related to each
transaction, such as a unique identifier, originating site, name, and so on. For
READ operations, it returns a local copy if valid and available. For WRITE operations, it ensures that updates are visible across all sites
containing copies (replicas) of the data item. For ABORT operations, the manager ensures that no effects of the transaction
are reflected in any site of the distributed database. For COMMIT operations, it ensures that the effects of a write are
persistently recorded on all databases containing copies of the data item.
Atomic termination (COMMIT/ ABORT) of distributed transactions is commonly
implemented using the two-phase commit protocol. We give more details of this
protocol in the following section.
The transaction manager passes to the
concurrency controller the database operation and associated information. The
controller is responsible for acquisition and release of associated locks. If
the transaction requires access to a locked resource, it is delayed until the
lock is acquired. Once the lock is acquired, the operation is sent to the
runtime processor, which handles the actual execution of the database
operation. Once the operation is completed, locks are released and the
transaction manager is updated with the result of the operation. We discuss
commonly used distributed concurrency methods in Section 25.7.
1. Two-Phase Commit Protocol
In Section 23.6, we described
the two-phase commit protocol (2PC), which requires a global recovery manager, or coordinator, to maintain information
needed for recovery, in addition to
the local recovery managers and the information they main-tain (log, tables)
The two-phase commit protocol has certain drawbacks that led to the development
of the three-phase commit protocol, which we discuss next.
2. Three-Phase Commit Protocol
The biggest drawback of 2PC is that it is a
blocking protocol. Failure of the coordinator blocks all participating sites,
causing them to wait until the coordinator recovers. This can cause
performance degradation, especially if participants are holding locks to shared
resources. Another problematic scenario is when both the coordinator and a
participant that has committed crash together. In the two-phase commit
protocol, a participant has no way to ensure that all participants got the
commit message in the second phase. Hence once a decision to commit has been
made by the coordinator in the first phase, participants will commit their
transactions in the second phase independent of receipt of a global commit
message by other participants. Thus, in the situation that both the
coordinator and a committed participant crash together, the result of the
transaction becomes uncertain or nondeterministic. Since the transaction has
already been committed by one participant, it cannot be aborted on recovery by
the coordinator. Also, the transaction cannot be optimistically committed on
recovery since the original vote of the coordinator may have been to abort.
These problems are solved by the three-phase
commit (3PC) protocol, which essentially divides the second commit phase into
two subphases called prepare-to-commit and commit. The prepare-to-commit phase is
used to communicate the result of
the vote phase to all participants. If all participants vote yes, then the
coordinator instructs them to move into the prepare-to-commit state. The
commit subphase is identical to its two-phase counterpart. Now, if the
coordinator crashes during this subphase, another participant can see the
transaction through to completion. It can simply ask a crashed participant if
it received a prepare-to-commit message. If it did not, then it safely assumes
to abort. Thus the state of the protocol can be recovered irrespective of which
participant crashes. Also, by limiting the time required for a transaction to
commit or abort to a maximum time-out period, the protocol ensures that a
transaction attempting to commit via 3PC releases locks on time-out.
The main idea is to limit the wait time for
participants who have committed and are waiting for a global commit or abort
from the coordinator. When a participant receives a precommit message, it knows
that the rest of the participants have voted to commit. If a precommit message
has not been received, then the participant will abort and release all locks.
3. Operating System Support for Transaction Management
The following are the main benefits of
operating system (OS)-supported transaction management:
1. Typically, DBMSs use their own semaphores to guarantee mutually exclusive access to shared resources. Since these semaphores are implemented in userspace at the level of the DBMS application software, the OS has no knowledge about them. Hence if the OS deactivates a DBMS process holding a lock, other DBMS processes wanting this lock resource get queued. Such a situation can cause serious performance degradation. OS-level knowledge of semaphores can help eliminate such situations.
2. Specialized hardware support for locking can be exploited to reduce associated costs. This can be of great importance, since locking is one of the most common DBMS operations.
3. Providing a set of common transaction support operations though the kernel allows application developers to focus on adding new features to their products as opposed to reimplementing the common functionality for each application. For example, if different DDBMSs are to coexist on the same machine and they chose the two-phase commit protocol, then it is more beneficial to have this protocol implemented as part of the kernel so that the DDBMS developers can focus more on adding new features to their products.