Chapter 3
Concurrency Control
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
Chapter 3 (Objectives)
Concurrency Control
Technique.
Deadlock
Database System Concepts - 5th Edition, Sep 12, 2006. 15.2 ©Silberschatz, Korth and Sudarshan
Concurrency Control
A policy in which only one transaction can execute at a
time generates serial schedules, but provides a poor
degree of concurrency.
A database must provide a mechanism that will ensure
that all possible schedules are
conflict serializable and recoverable
Concurrency-control protocols allow concurrent
schedules, but ensure that the schedules are conflict
serializable, and are recoverable
Database System Concepts - 5th Edition, Sep 12, 2006. 15.3 ©Silberschatz, Korth and Sudarshan
Objective Of a Concurrency Control Protocol
To schedule transactions in such a way as to avoid
any interference between them and hence prevent
the type of problems caused by concurrency.
One obvious solution is to allow only one
transaction to execute at a time:
One transaction is committed before the next
transaction is allowed to begin.
However, the aim of a multi-user DBMS is to
maximize the degree of concurrency.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.4 ©Silberschatz, Korth and Sudarshan
Concurrency Control Techniques
Most of these techniques ensure serializability of schedules using
protocols that guarantee serializability.
The two main concurrency control techniques:
Locking
Timestamping
Locking
A procedure to control concurrent access to data. When one
transaction is accessing the database, the lock may deny access to
other transactions .
A lock is a control placed in the database to reserve data so that only
one database user may update it.
When data is locked, no other database session can update the data
until the lock is released. Any other session that attempts to update
locked data will be placed in a lock wait state.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.5 ©Silberschatz, Korth and Sudarshan
Concurrency Control with Locking
Methods
A transaction acquires a lock prior to data access;
The lock is released (unlocked) when the transaction is
completed so that another transaction can lock the data item for
its exclusive use.
The use of locks based on the assumption that conflict between
transactions is likely to occur is often referred to as pessimistic
locking.
Most multiuser DBMSs automatically initiate and enforce locking
procedures. All lock information is managed by a lock manager,
which is responsible for assigning and policing the locks used by
the transactions
Lock Granularity: indicates the level of lock use. Locking can
take place at the following levels: database, table, page, row, or
even field (attribute).
Database System Concepts - 5th Edition, Sep 12, 2006. 15.6 ©Silberschatz, Korth and Sudarshan
Database Lock
Database System Concepts - 5th Edition, Sep 12, 2006. 15.7 ©Silberschatz, Korth and Sudarshan
Database Lock
In a database-level lock, the entire database is locked,
thus preventing the use of any tables in the database by
transaction T2 while transaction Tl is being executed.
This level of locking is unsuitable for multiuser DBMSs.
Data access will be very s-l-o-w.
Transactions T1 and T2 cannot access the same
database concurrently even when they use different
tables.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.8 ©Silberschatz, Korth and Sudarshan
Table Level
Database System Concepts - 5th Edition, Sep 12, 2006. 15.9 ©Silberschatz, Korth and Sudarshan
Table Level
In a table-level lock, the entire table is locked, preventing access
to any row by transaction T2 while transaction T1 is using the table.
If a transaction requires access to several tables, each table may
be locked.
However, two transactions can access the same database as
long as they access different tables.
Table-level locks are less restrictive than database-level locks.
When different transactions require access to different parts of the
same table & when the transactions would not interfere with each
other this lock is not suitable for multiuser DBMSs.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.10 ©Silberschatz, Korth and Sudarshan
Page Level
Database System Concepts - 5th Edition, Sep 12, 2006. 15.11 ©Silberschatz, Korth and Sudarshan
Page level
In a page-level lock, the DBMS will lock an entire diskpage.
A diskpage, or page, is the equivalent of a diskblock, is a
directly addressable section of a disk.
A table can span several pages, and a page can contain several
rows of one or more tables.
Page-level locks are currently the most frequently used multiuser
DBMS locking method.
In Figure,T1 &T2 access the same table while locking different
diskpages. If T2 requires the use of a row located on a page that
is locked by T1, T2 must wait until the page is unlocked by T1.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.12 ©Silberschatz, Korth and Sudarshan
Row level
Database System Concepts - 5th Edition, Sep 12, 2006. 15.13 ©Silberschatz, Korth and Sudarshan
Row level
A row-level lock is much less restrictive.
The DBMS allows concurrent transactions to access different rows of
the same table even when the rows are located on the same page.
Although the row-level locking approach improves the availability of
data, its management requires high overhead because a lock exists
for each row in a table of the database involved in a conflicting
transaction.
Modern DBMSs automatically changes a lock from a row-level to a
page-level lock when the application session requests multiple locks
on the same page.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.14 ©Silberschatz, Korth and Sudarshan
Field level lock
The field-level lock allows concurrent transactions
to access the same row as long as they require the
use of different fields (attributes) within that row.
Although field-level locking clearly yields the most
flexible multiuser data access, it is rarely
implemented in a DBMS because it requires an
extremely high level of computer overhead.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.15 ©Silberschatz, Korth and Sudarshan
Lock Types
Regardless of the level of locking, the DBMS may
use different lock types:
Binary
Shared/exclusive.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.16 ©Silberschatz, Korth and Sudarshan
Binary Lock
A binary lock has only two states: locked (1) or unlocked (0).
Every transaction requires a lock and unlock operation
for each data item that is accessed.
Such operations are automatically managed and
scheduled by the DBMS; the user does not need to be
concerned about locking or unlocking data items.
If the end user wants to override the default, the LOCK
TABLE and other SQL commands are available for that
purpose.
Binary locks are now considered too restrictive to yield
optimal concurrency conditions. For example, the DBMS
will not allow two transactions to read the same database
object even though neither transaction updates the database,
and therefore, no concurrency problems can occur.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.17 ©Silberschatz, Korth and Sudarshan
Shared/Exclusive Locks
The labels “shared” and “exclusive” indicate the nature of
the lock.
An exclusive lock exists when access is reserved
specifically for the transaction that locked the object.
The exclusive lock must be used when the potential for
conflict exists.
A shared lock exists when concurrent transactions are
granted read access on the basis of a common lock. A
shared lock produces no conflict as long as all the
concurrent transactions are read-only.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.18 ©Silberschatz, Korth and Sudarshan
Shared/Exclusive Locks
A shared lock is issued when a transaction wants to read
data from the database and no exclusive lock is held
on that data item.
An exclusive lock is issued when a transaction wants to
update (write) a data item and no locks are currently
held on that data item by any other transaction.
Using the shared/exclusive locking concept, a lock can
have three states: unlocked, shared (read), and exclusive
(write).
Database System Concepts - 5th Edition, Sep 12, 2006. 15.19 ©Silberschatz, Korth and Sudarshan
Shared/Exclusive Locks
Shared locks allow several Read transactions to read the same data
item concurrently. E.g: if T1 has a shared lock on X and T2 wants to
X, T2 also obtains a shared lock on X.
If T2 updates X, an exclusive lock is required by T2 over X.
The exclusive lock is granted if and only if no other locks are held
on the data item. If a shared or exclusive lock is already held on X
by T1, an exclusive lock cannot be granted to T2 and T2 must wait
to begin until T1 commits.
This condition is known as the mutual exclusive rule: only one
transaction at a time can own an exclusive lock on the same
object.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.20 ©Silberschatz, Korth and Sudarshan
Shared/Exclusive
Increases the lock manager’s overhead.
1. The type of lock held must be known before a lock can be
granted.
2. Three lock operations exist: READ_LOCK (to check the
type of lock), WRITE_LOCK (to issue the lock), and
UNLOCK (to release the lock).
3. The schema has been enhanced to allow a lock upgrade
(from shared to exclusive) and a lock downgrade (from
exclusive to shared).
Database System Concepts - 5th Edition, Sep 12, 2006. 15.21 ©Silberschatz, Korth and Sudarshan
Two-Phase Locking to Ensure
Serializability
Two-phase locking defines how transactions acquire
and relinquish locks. Two-phase locking guarantees
serializability, but it does not prevent deadlocks.
The two phases are:
A growing phase, in which a transaction acquires all
required locks without unlocking any data. Once all locks
have been acquired, the transaction is in its locked point.
A shrinking phase, in which a transaction releases all
locks and cannot obtain any new lock.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.23 ©Silberschatz, Korth and Sudarshan
Two Phase Locking
The two-phase locking protocol is governed by the
following rules:
1. Two transactions cannot have conflicting locks.
2. No unlock operation can precede a lock operation in the
same transaction.
3. No data are affected until all locks are obtained—that is,
until the transaction is in its locked point.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.24 ©Silberschatz, Korth and Sudarshan
Two phase locking
Database System Concepts - 5th Edition, Sep 12, 2006. 15.25 ©Silberschatz, Korth and Sudarshan
Two Phase Locking
In this figure, the transaction acquires all of the locks it needs
until it reaches its locked point.
When the locked point is reached, the data are modified to
conform to the transaction’s requirements.
Finally, the transaction is completed as it releases all of the
locks it acquired in the first phase.
Two-phase locking increases the transaction processing cost
and might cause additional undesirable effects. One
undesirable effect is the possibility of creating deadlocks
Database System Concepts - 5th Edition, Sep 12, 2006. 15.26 ©Silberschatz, Korth and Sudarshan
Deadlock
A deadlock occurs when two transactions wait indefinitely
for each other to unlock data.
For e.g : the two transactions T1 & T2 are deadlocked when
T1 is on the waiting queue for X, which is locked by T2,
while T2 is on the waiting queue for Y which is locked by
T1. Meanwhile neither T1 nor T2 nor any other transaction
can access items X & Y.
Deadlocks are possible only when one of the transactions
wants to obtain an exclusive lock on a data item; no
deadlock condition can exist among shared locks.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.27 ©Silberschatz, Korth and Sudarshan
Handling Deadlocks
Deadlock prevention. A transaction requesting a new lock is aborted when
there is the possibility that a deadlock can occur. If the transaction is
aborted, all changes made by this transaction are rolled back and all locks
obtained by the transaction are released. The transaction is then
rescheduled for execution. Deadlock prevention works because it avoids the
conditions that lead to deadlocking.
Deadlock detection. The DBMS periodically tests the database for
deadlocks. If a deadlock is found, one of the transactions (the “victim”) is
aborted (rolled back and restarted) and the other transaction continues.
Deadlock avoidance. The transaction must obtain all of the locks it needs
before it can be executed. This technique avoids the rolling back of
conflicting transactions by requiring that locks be obtained in succession.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.28 ©Silberschatz, Korth and Sudarshan
Handling Deadlocks
The choice of the best deadlock control method to use depends
on the database environment.
If the probability of deadlocks is lowdeadlock detection If the
probability of deadlocks is high deadlock prevention.
If response time is not high on the system’s priority
listdeadlock avoidance .
All current DBMSs support deadlock detection in transactional
databases, while some DBMSs use a blend of prevention and
avoidance techniques for other types of data, such as data
warehouses or XML data.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.29 ©Silberschatz, Korth and Sudarshan
Concurrency Control Techniques
Timestamping
A timestamp is a unique identifier for each transaction,
generated by the system.
Indicates the relative starting time of a transaction.
Time stamps must have two properties: uniqueness and
monotonicity. Uniqueness ensures that no equal time
stamp values can exist, and monotonicity ensures that
time stamp values always increase.
Transactions with smaller timestamps get priority in the event
of conflict.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.30 ©Silberschatz, Korth and Sudarshan
Timestamping
Two schemes used to decide which transaction is
rolled back and which continues executing
Wait/Die
Wound/Wait Schemes
(Older the transaction lower the time stamp value
and higher the timestamp the newer the transaction.)
Database System Concepts - 5th Edition, Sep 12, 2006. 15.31 ©Silberschatz, Korth and Sudarshan
Database System Concepts - 5th Edition, Sep 12, 2006. 15.32 ©Silberschatz, Korth and Sudarshan
Time Stamping
Using the wait/die scheme:
If the transaction requesting the lock is the older of the two
transactions, it will wait until the other transaction is
completed and the locks are released.
If the transaction requesting the lock is the younger of the
two transactions, it will die (roll back) and is rescheduled
using the same time stamp.
In short, in the wait/die scheme, the older transaction
waits for the younger to complete and release its locks.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.33 ©Silberschatz, Korth and Sudarshan
Time Stamping
Using the wound/wait scheme:
If the transaction requesting the lock is the older of the two
transactions, it will preempt (wound) the younger transaction (by
rolling it back). T1 preempts T2 when T1 rolls back T2. The
younger, preempted transaction is rescheduled using the same
time stamp.
If the transaction requesting the lock is the younger of the two
transactions, it will wait until the other transaction is completed
and the locks are released.
In short, in the wound/wait scheme, the older transaction rolls
back the younger transaction and reschedules it.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.34 ©Silberschatz, Korth and Sudarshan
Time Stamping
In both schemes, one of the transactions waits for the other
transaction to finish and release the locks.
Some scenario’s can cause transactions to wait indefinitely,
causing a deadlock.
To prevent that type of deadlock, each lock request has an
associated time-out value.
If the lock is not granted before the time-out expires, the
transaction is rolled back.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.35 ©Silberschatz, Korth and Sudarshan
Concurrency control with Optimistic
(Vaildation)Methods
The optimistic approach is based on the
assumption that the majority of the
database operations do not conflict.
The optimistic approach requires neither
locking nor time stamping techniques.
Instead, a transaction is executed without
restrictions until it is committed. Using an
optimistic approach, each transaction
moves through two or three phases,
referred to as read, validation, and write.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.36 ©Silberschatz, Korth and Sudarshan
Optimistic (Vaildation)Methods
During the read phase, the transaction reads the committed
data items from the database, executes the needed
computations, and makes the updates to a private copy of the
database values. All update operations of the transaction are
recorded in a temporary update file(transaction workspace),
which is not accessed by the remaining transactions.
During the validation phase, the transaction is validated to
ensure that the changes made will not affect the integrity and
consistency of the database. (to ensure that serializability will
not be violated)If the validation test is positive, the transaction
goes to the write phase. If the validation test is negative, the
transaction is restarted and the changes are discarded.
During the write phase, the changes are permanently applied
to the database.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.37 ©Silberschatz, Korth and Sudarshan
Optimistic (Vaildation)Methods
The optimistic approach is acceptable for most read or query
database systems that require few update transactions.
Transaction execution proceeds with a minimum of overhead
until the validation phase is reached. If there is little
interference among transcations most will be validated
successfully.
The technique is called optimistic because they assume that
little interference will occure and hence that there is no need to
do checking during transcation execution.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.38 ©Silberschatz, Korth and Sudarshan
End of Chapter 3
Edited : Mrs.Pravicha.M.T
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
