Browse Prior Art Database

Using Commit Bits to Reduce Locking in Transaction Processing Systems

IP.com Disclosure Number: IPCOM000105772D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 157K

Publishing Venue

IBM

Related People

Lee, CM: AUTHOR [+4]

Abstract

Disclosed is a new way to determine if data is in the committed state without locking through the use of commit bits. Under certain conditions, transactions can easily determine that the data is committed simply by checking the value of a bit.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 31% of the total text.

Using Commit Bits to Reduce Locking in Transaction Processing Systems

      Disclosed is a new way to determine if data is in the committed
state without locking through the use of commit bits.  Under certain
conditions, transactions can easily determine that the data is
committed simply by checking the value of a bit.

      One of the key issues in database management systems today is
determining when data is committed so that it can be accessed by a
transaction.  A transaction cannot update data that is not committed
and for Cursor Stability and Repeatable Read isolation levels, a
transaction may not even read data until it is committed.  The method
chosen to determine when data is committed affects both the
performance and level of concurrency of the database system.  Two
solutions which currently address this issue are locking and
Commit_LSN [*].

      The first solution for commit determination is locking which
has been the traditional method in the past.  Locks can only be
acquired once the data is in the committed state.  A lock is held
while data is uncommitted so that no other transactions can acquire
the same lock and access the uncommitted data.  Although locks solve
the problem, there are significant drawbacks to this solution.
Locking seriously degrades performance because of the long pathlength
required.  In addition, concurrency is reduced because no other
transactions can access the data while the lock is held.  Locks also
require storage space and are plagued by deadlocks and timeouts.

      Because locking has such a high cost, a second solution called
Commit_LSN was developed.  Commit_LSN is a log sequence number (LSN)
such that all updates logged prior to or equal to this value have
been committed.  Therefore, if the LSN on a page is less than or
equal to the Commit_LSN value, all data on that page is in the
committed state.  Nevertheless, Commit_LSN also has its own
drawbacks.  Although it avoids the cost of locking, the level of
granularity is limited at the page level.  Commit_LSN will fail if a
single entry on a page has been inserted, deleted, or updated.  Once
Commit_LSN fails, it is unknown which entries are in the committed
state.  As a result, the transaction must resort to locking each
entry accessed on the page regardless of whether the entry is
committed or not.

      Because locking and Commit_LSN have these disadvantages, a new
method has been developed to determine if data is in the committed
state.  Commit bits are used as flags to signal when data is
committed or not.  A bit is associated with a particular object or
piece of data.  This bit is initialized to a value which will have a
certain meaning.  For example, the bit could be initialized to zero
to indicate that the object corresponding to the bit is not
committed.  The value of the bit would be modified when the commit
status of the object changed.  In this example, the bit would be set
to one when the o...