Concurrency Control

Concurrency Control Techniques
In this chapter, number of concurrency control techniques that are used to ensure the
noninterference or isolation property of concurrently executing transactions. Most of these
techniques ensure serializability of schedules—using concurrency control protocols (sets of
rules) that guarantee serializability. One important set of protocols—known as two-phase
locking protocols— employs the technique of locking data items to prevent multiple
transactions from accessing the items concurrently; Another set of concurrency control
protocols uses timestamps. A timestamp is a unique identifier for each transaction, generated
by the system. Timestamp values are generated in the same order as the transaction start
times; multiversion concurrency control protocols that use multiple versions of a data item.
Concept of validation or certification of a transaction after it executes its operations; these are
sometimes called optimistic protocols, and they also assume that multiple versions of a data
item can exist.
Two-Phase Locking Techniques for Concurrency Control

A lock is a variable associated with a data item that describes the status of the item with
respect to possible operations that can be applied to it. Generally, there is one lock for each
data item in the database. Locks are used as a means of synchronizing the access by concurrent
transactions to the database items.
Types of Locks and System Lock Tables
Binary Locks
A binary lock can have two states or values: locked and unlocked (or 1 and 0, for simplicity). A
distinct lock is associated with each database item X. If the value of the lock on X is 1, item X
cannot be accessed by a database operation that requests the item. If the value of the lock on X
is 0, the item can be accessed when requested, and the lock value is changed to 1. We refer to
the current value (or state) of the lock associated with item X as lock(X).
Two operations, lock_item and unlock_item, are used with binary locking. A transaction
requests access to an item X by first issuing a lock_item(X) operation. If LOCK(X) = 1, the
transaction is forced to wait. If LOCK(X) = 0, it is set to 1 (the transaction locks the item) and the
transaction is allowed to access item X. When the transaction is through using the item, it issues
an unlock_item(X) operation, which sets LOCK(X) back to 0 (unlocks the item) so that X may be
accessed by other transactions. Hence, a binary lock enforces mutual exclusion on the data
item.
It is simple to implement a binary lock; all that is needed is a binary-valued variable, LOCK,
associated with each data item X in the database. In its simplest form, each lock can be a record
with three fields: plus a queue for transactions that are waiting to access the item. The system
needs to maintain only these records for the items that are currently locked in a lock table,
which could be organized as a hash file on the item name. Items not in the lock table are
considered to be unlocked. The DBMS has a lock manager subsystem to keep track of and
control access to locks.
If the simple binary locking scheme described here is used, every transaction must obey the
following rules:
1. A transaction T must issue the operation lock_item(X) before any read_item(X) or

write_item(X) operations are performed in T.
2. A transaction T must issue the operation unlock_item(X) after all read_item(X) and
write_item(X) operations are completed in T.
3. A transaction T will not issue a lock_item(X) operation if it already holds the lock on item
X.
4. A transaction T will not issue an unlock_item(X) operation unless it already holds the
lock on item X.
Shared/Exclusive (or Read/Write) Locks.
The preceding binary locking scheme is too restrictive for database items because at most one
transaction can hold a lock on a given item. For this purpose, a different type of lock, called a
multiple-mode lock, is used. In this scheme—called shared/exclusive or read/write locks—there
are three locking operations: read_lock(X), write_lock(X), and unlock(X). A lock associated with
an item X, LOCK(X), now has three possible states: read-locked, write-locked, or unlocked. A
read-locked item is also called share-locked because other transactions are allowed to read the
item, whereas a write-locked item is called exclusive-locked because a single transaction
exclusively holds the lock on the item.
One method for implementing the preceding operations on a read/write lock is to keep track of
the number of transactions that hold a shared (read) lock on an item in the lock table, as well as
a list of transaction ids that hold a shared lock. Each record in the lock table will have four
fields: <Data_item_name, LOCK, No_of_reads, locking_transaction(s)> . The system needs to
maintain lock records only for locked items in the lock table.
The value (state) of LOCK is either readlocked or write-locked, suitably coded (if we assume no
records are kept in the lock table for unlocked items). If LOCK(X) = write-locked, the value of
locking_transaction(s) is a single transaction that holds the exclusive (write) lock on X. If
LOCK(X)=read-locked, the value of locking transaction(s) is a list of one or more transactions
that hold the shared (read) lock on X.
When we use the shared/exclusive locking scheme, the system must enforce the following
rules:
1. A transaction T must issue the operation read_lock(X) or write_lock(X) before any

read_item(X) operation is performed in T.
2. A transaction T must issue the operation write_lock(X) before any write_item(X)
operation is performed in T.
3. A transaction T must issue the operation unlock(X) after all read_item(X) and
write_item(X) operations are completed in T
4. A transaction T will not issue a read_lock(X) operation if it already holds a read
(shared) lock or a write (exclusive) lock on item X. This rule may be relaxed for
downgrading of locks
5. A transaction T will not issue a write_lock(X) operation if it already holds a read
(shared) lock or write (exclusive) lock on item X. This rule may also be relaxed for
upgrading of locks
6. A transaction T will not issue an unlock(X) operation unless it already holds a read
(shared) lock or a write (exclusive) lock on item X

Concurrency Control

Uploaded by

Copyright:

Available Formats

Concurrency Control

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Concurrency Control

Uploaded by

Copyright:

Available Formats

Concurrency Control Techniques

Two-Phase Locking Techniques for Concurrency Control

Types of Locks and System Lock Tables

1. A transaction T must issue the operation lock_item(X) before any read_item(X) or

Shared/Exclusive (or Read/Write) Locks.

1. A transaction T must issue the operation read_lock(X) or write_lock(X) before any

You might also like