Concurrency Control

using Locking Methods

  A lock guarantees exclusive use of a data item to a current
transaction. In other words, transaction T2 does not have access to a
data item that is currently being used by transaction T1.

 A transaction acquires a lock prior to data access; the lock is

released (unlocked) when the transaction is completed so that
Concurrency another transaction can lock the data item for its exclusive use.
Control with
 The use of locks based on the assumption that conflict between
Locking
transactions is likely to occur is often referred to as pessimistic
Methods locking.

 All lock information is managed by a lock manager of DBMS, 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 Level

Lock  Table Level

Granularity  Page Level

 Row Level

 Field Level
  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 good for batch

Database processes, but it is unsuitable for
Level multiuser DBMSs.

 The data access would be slow if

thousands of transactions had to
wait for the previous transaction to
be completed before the next one
could reserve the entire database.
  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 different
tables of same database.
Table  Table-level locks, while less restrictive than
Level database-level locks, cause traffic jams
when many transactions are waiting to
access the same table.

 Consequently, table-level locks are not

suitable for multiuser DBMSs.

 In Figure, transactions T1 and T2 cannot

access the same table even when they try to
use different rows; T2 must wait until T1
unlocks the table
  A table can span several pages, and a
page can contain several rows of one or
more tables.

 In a page-level lock, the DBMS will lock

an entire disk page.

 A disk page, or page, is the equivalent of

Page a disk block, is the directly addressable
Level section of a disk.

 A page has a fixed size, such as 4K, 8K,

or 16K. For example, if you want to
write only 73 bytes to a 4K page, the
entire 4K page must be read from disk,
updated in memory, and written back
to disk.
  Page-level locks are currently the
most frequently used multiuser
DBMS locking method.

Page  In figure, T1 and T2 access the

Level 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
  In Row-level, 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 escalate a lock from a row-level to a page-level

Row Level lock when the application session requests multiple locks on the same page.
  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.

Field Level  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 and
because the row-level lock is much more useful in
practice
 Two different lock types: binary or shared/exclusive.
1. Binary Locks
 A binary lock has only two states: locked (1) or unlocked (0) state.

 If an object (database/table/page/row) is locked by a transaction, no other

transaction can use that object. if an object is unlocked, any transaction can
lock the object for its use.
Lock Types  Every database operation requires that the affected object be locked and the
transaction must unlock the object after its termination. So, every transaction
requires a lock and unlock operation for each data item that is accessed.

 These operations are automatically managed and scheduled by DBMS; the user
does not need to be concerned about locking or unlocking data items. (Every
DBMS has a default locking mechanism. If the user wants to override the
default, LOCK TABLE and other SQL commands are available for that purpose.)
Lock Types
 The lock and unlock features in the figure eliminate the
lost update problem because the lock is not released
until the WRITE statement is completed.

 Therefore, a PROD_QOH value cannot be used until it has

been properly updated.
 2. Shared/Exclusive Locks

 The labels “shared” and “exclusive” indicate the nature of the

lock.

 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
Lock Types
are read-only.

 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).
  Because the two Read transactions can be safely executed at once,
shared locks allow several Read transactions to read the same data item
concurrently. For example, if transaction T1 has a shared lock on data
item X and transaction T2 wants to read data item X, T2 may also obtain
a shared lock on data item X.

 If transaction T2 updates data item X, an exclusive lock is required by

Lock Types T2 over data item X. The exclusive lock is granted if and only if no other
locks are held on the data item.

 Therefore, if a shared or exclusive lock is already held on data item X by

transaction T1, an exclusive lock cannot be granted to transaction 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.
  Although the use of shared locks renders data access more
efficient, a shared/exclusive lock schema increases the lock
manager’s overhead, for several reasons: The type of lock
held must be known before a lock can be granted.

 Three lock operations exist:

Lock Types  READ_LOCK (to check the type of lock),

 WRITE_LOCK (to issue the lock), and

 UNLOCK (to release the lock).

 The schema has been enhanced to allow a lock upgrade

(from shared to exclusive) and a lock downgrade (from
exclusive to shared)
  Although locks prevent serious data inconsistencies, they can lead
to two major problems:
 The resulting transaction schedule might not be
serializable.

 The schedule might create deadlocks. A deadlock occurs

when two transactions wait indefinitely for each other to
Lock Types
unlock data.

 Solutions :
 serializability is guaranteed through a locking protocol known
as two-phase locking, and

 deadlocks can be managed by using deadlock detection and

prevention techniques.
 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:

1. A growing phase, in which a transaction acquires all required

2PL to ensure
locks without unlocking any data. Once all locks have been
Serializability
acquired, the transaction is in its locked point.

2. A shrinking phase, in which a transaction releases all locks and

cannot obtain any new lock.

The two-phase locking protocol is governed by the following rules:

 Two transactions cannot have conflicting locks.

 No unlock operation can precede a lock operation in the same

transaction.

 No data are affected until all locks are obtained—that is, until the
transaction is in its locked point
  In this example, the transaction acquires all of the locks
it needs until it reaches its locked point. (In this example,

2PL the transaction requires two locks.)

 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.
 Transaction T1:
• The growing Phase is from steps 1-3.
• The shrinking Phase is from steps 5-7.
• Lock Point at 3

2PL Transaction T2:

• The growing Phase is from steps 2-6.
• The shrinking Phase is from steps 8-9.
• Lock Point at 6

LOCK POINT : The Point at which the growing

phase ends, i.e., when a transaction takes the final
lock it needs to carry on its work.
Consider the transactions T31 & T32. Add lock and unlock instructions to transactions T31 & T32., so
that they observe the 2PL. Can the execution of these transactions result in a deadlock?

T31: read(A); T32: read(B);

read(B); read(A);
if A = 0 then B := B + 1; if B = 0 then A := A + 1;
write(B). write(A).

Lock and unlock instructions: Execution of these transactions can result in deadlock.
For example, consider the following partial schedule:
T31: lock-S(A) T32: lock-S(B)
read(A) read(B)
lock-X(B) lock-X(A)
read(B) read(A)
if A = 0 then B := B + 1 if B = 0 then A := A + 1
write(B) write(A)
unlock(A) unlock(B)
unlock(B) unlock(A)