Information Technology Reference
In-Depth Information
applications. The structures also lend themselves to implementations on new
hardware such as flash-memory-based solid-disk drives ( SSD s), where reads and
sequential append-only writes are faster than on hard disk, but random in-place
writes are expensive.
15.1
Group Commit
According to the basic commit protocol presented in Sect. 3.8 , the log is flushed onto
the log disk every time a transaction commits (Algorithm 3.3 ). Assume that there
are many short transactions, each updating only a single tuple in the database, and
that a log-file page can hold the log records (begin-transaction, update log record,
commit transaction) for n such transactions. Then the same log-file page is written
from the log buffer onto disk n times, and these writes are all random disk writes,
with at least one rotational delay in between. Moreover, there is a fixed overhead
associated with initializing and completing any disk write.
The log file being a sequential file, a natural optimization is to flush only full
pages and to flush as many pages as possible using a single sequential disk write.
If a group of k full log-file pages are written by a single sequential disk write, the
amortized disk-write cost of committing a short transaction may be as low as 1=.k n/
times the cost of flushing a single page. The kn transactions are all considered
committed once their log records are on the log disk.
The above procedure, in which the log is not flushed at every commit action,
is called group commit . The application process on whose behalf a transaction is
executed by some server-process thread is notified of the commit only after the
log has been flushed next time, that is, when the transaction has committed in the
original sense of the concept.
Obviously, a group commit delays the commit of individual transactions and
hence decreases the durability of successfully terminated transactions under system
crashes: a transaction that has appended its commit log record into the log buffer
may still abort and roll back if a system crash occurs before the next log flush.
Moreover, a large set of transactions waiting for their group to be committed by
the next log flush may all hold commit-duration locks on data items they have read
or written, thus possibly blocking other transactions that want to access those data
items. This raises the question of whether the transactions that wait to be committed
can release their locks before the log has been flushed. We will show in the following
that this indeed is possible.
In the context of write-ahead logging and lock-based concurrency control, we
say that a transaction is precommitted if it has appended its commit log record into
the log buffer and released its locks and is waiting for the log to be flushed. A
precommitted transaction T will commit, and the application will be notified of the
commit, if no system crash occurs beforethenextlogflush;otherwise,T will roll
back. If the server-process thread executing T fails after T has precommitted, T
Search WWH ::




Custom Search