Transaction and System Concepts
In this section we discuss additional concepts relevant to transaction
processing. Section 1 describes the various states a transaction can be
in, and discusses other operations needed in transaction processing. Section 2 discusses the system log, which keeps information about transactions
and data items that will be needed for recovery. Section 3 describes the
concept of commit points of trans-actions, and why they are important in
transaction processing.
1. Transaction States
and Additional Operations
A transaction is an atomic unit of work that should either be completed
in its entirety or not done at all. For recovery purposes, the system needs to
keep track of when each transaction starts, terminates, and commits or aborts . Therefore, the recovery manager of the DBMS needs to keep
track of the following operations:
BEGIN_TRANSACTION. This marks the beginning of
transaction execution.
READ or WRITE. These
specify read or write operations on the database
items that are executed as part of a transaction.
■ END_TRANSACTION. This specifies that READ and WRITE transaction
operations have ended and marks the end of transaction execution. However, at
this point it may be necessary to check whether the changes introduced by the
transaction can be permanently applied to the database (committed) or whether
the transaction has to be aborted because it violates serializability (see
Section 21.5) or for some other reason.
■ COMMIT_TRANSACTION. This signals a successful
end
of the transaction so that any
changes (updates) executed by the transaction can be safely committed to the database and will not
be undone.
■ ROLLBACK (or
ABORT). This signals that the transaction has ended unsuccessfully, so that any changes or effects that the transaction may have applied to the database must be undone.
Figure 21.4 shows a state transition diagram that illustrates how a
transaction moves through its execution states. A transaction goes into an active state immediately after it
starts execution, where it can execute its READ and WRITE operations. When the transaction ends, it moves to the partially committed state. At this
point, some recovery protocols need to ensure that a system failure will not
result in an inability to record the changes of the transaction permanently
(usually by recording changes in the system log, discussed in the next
section).5 Once this check is successful, the transaction is said to have reached
its commit point and enters the committed
state. Commit points are discussed in more detail in Section 21.2.3. When a
transaction is committed, it has concluded its execution successfully and all
its changes must be recorded permanently in the database, even if a system
failure occurs.
However, a transaction can go to the failed state if one of the checks fails or if the transaction is
aborted during its active state. The transaction may then have to be rolled
back to undo the effect of its WRITE operations on the database. The terminated state corresponds to the
transaction leaving the system. The transaction information that is maintained in system tables while the
transaction has been run-ning is removed when the transaction terminates.
Failed or aborted transactions may be restarted
later—either automatically or after being resubmitted by the user—as brand new
transactions.
2. The System Log
To be able to recover from failures that affect transactions, the system
maintains a log6 to keep track of all transaction
operations that affect the values of database items, as well as other transaction information that may be needed
to permit recovery from failures. The log is a sequential, append-only file
that is kept on disk, so it is not affected by any type of failure except for
disk or catastrophic failure. Typically, one (or more) main memory buffers hold
the last part of the log file, so that log entries are first added to the main
memory buffer. When the log buffer
is filled, or when certain other conditions occur, the log buffer is appended to the end of the log file on disk. In addition, the log file
from disk is periodically backed up to archival storage (tape) to guard against catastrophic failures. The
following are the types of entries—called log
records—that are written to the log file and the corresponding action for
each log record. In these entries, T
refers to a unique transaction-id
that is generated automatically by the system for each transaction and that is
used to identify each transaction:
[start_transaction, T]. Indicates that transaction T has started execution.
[write_item, T, X, old_value, new_value]. Indicates that transaction T has changed the value of database item X from old_value to new_value.
[read_item, T, X]. Indicates that transaction T
has read the value of database item
X.
[commit, T]. Indicates that transaction T has completed successfully, and affirms that its effect can be
committed (recorded permanently) to the data-base.
[abort, T]. Indicates that transaction T has been aborted.
Protocols for recovery that avoid cascading rollbacks (see Section
21.4.2)—which include nearly all practical protocols—do not require that READ
operations are writ-ten to the system log. However, if the log is also used for
other purposes—such as auditing (keeping track of all database operations)—then
such entries can be included. Additionally, some recovery protocols require
simpler WRITE entries only include one of new_value and old_value instead of including both (see Section 21.4.2).
Notice that we are assuming that all permanent changes to the database
occur within transactions, so the notion of recovery from a transaction failure
amounts to either undoing or redoing transaction operations individually from
the log. If the system crashes, we can recover to a consistent database state
by examining the log and using one of the techniques described in Chapter 23.
Because the log contains a record of every WRITE
operation that changes the value of some database item, it is possible to undo the effect of these WRITE operations of a transaction T
by tracing backward through the log and resetting all items changed by a WRITE operation of T to their old_values. Redo of an operation may also be necessary
if a transaction has its updates
recorded in the log but a failure occurs before the system can be sure that all
these new_values have been written to the actual database on disk from the main memory
buffers.
3. Commit Point of a
Transaction
A transaction T reaches its commit point when all its operations
that access the database have been executed successfully and the effect of all the transaction operations on the database
have been recorded in the log. Beyond the commit point, the transaction is said
to be committed, and its effect must
be permanently recorded in the
database. The transaction then writes a commit record [commit, T] into the log. If a system
failure occurs, we can search back in the log for all transactions T that have written a [start_transaction, T] record into the log but
have not written their [commit, T] record yet; these transactions may have to be rolled back to undo their effect on the
database during the recovery process. Transactions that have written their commit record in the log must
also have recorded all their WRITE operations in the log, so their
effect on the database can be redone
from the log records.
Notice that the log file must be kept on disk. As discussed in Chapter
17, updating a disk file involves copying the appropriate block of the file from
disk to a buffer in main memory, updating the buffer in main memory, and
copying the buffer to disk. It is common to keep one or more blocks of the log
file in main memory buffers, called the log
buffer, until they are filled with log entries and then to write them back
to disk only once, rather than writing to disk every time a log entry is added.
This saves the overhead of multiple disk writes of the same log file buffer. At
the time of a system crash, only the log entries that have been written back to disk are considered in
the recovery process because the contents of main memory may be lost. Hence, before a transaction reaches its commit
point, any portion of the log that has not been written to the disk yet must
now be written to the disk. This process is called force-writing the log buffer before committing a transaction.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.