Advanced Database system(CoSc2072)

Chapter -4
Concurrency Control
 Concurrency control — ensuring that each user appears
to execute in isolation.
 It is the procedure in DBMS for managing simultaneous
operations without conflicting with each another. 
 Why?
 Lost Updates 
 Temporary update (dirty read)
 Non-Repeatable Read 
 Incorrect Summary issue
 Concurrency Control Algorithms
– Pessimistic methods assume that many transactions will conflict, thus the
concurrent execution of transactions is synchronized early in their execution life
cycle

∗ Two-Phase Locking (2PL)

∗ Timestamp Ordering (TO)
 Multiversion TO

– Optimistic methods assume that not too many transactions will conflict, thus
delay the synchronization of transactions until their termination

∗ Locking-based

∗ Timestamp ordering-based
Locking Based Algorithms
 A lock is a mechanism to control concurrent access to a data
item
 Binary Locks - will have 2 values locked and unlocked
represented as 0 and 1.

 A transaction sends a request to a data manager to access data

item by first locking the data item using LOCK() operation

 Transaction tries to access same data item then it is forced to wait
until the transaction that has locked unlock the data item.
Rules in binary locking technique:
 LOCK() : operation must be issued by transaction before any
update operation like read() or write() operation.
 LOCK() :can’t be issued by transaction if already holds
LOCK() on data item
 UNLOCK() : must be issued after all read() and write()
operations are completed in a transaction.
 UNLOCK(): can’t be issued by transaction unless it already
hold the lock on the data item.
Example for binary lock
T1:LOCK(A)
T1:READ(A) A=100  This example is seriazible
T1:A:=A+200 A=300
schedule.
T1:WRITE(A)
T1:UNLOCK(A)  Therefore, in case of a binary
T2:LOCK(A)
locking mechanism at most one
T2:READ(A)
A=300 transaction can hold the lock on a
T2:A:=A+300 A=600
T2:WRITE(A) A=600 particular data item .
T2:UNLOCK(A)  Thus no transaction can access
the same item concurrently.
Type of Lock modes
 shared (S) mode
 Exclusive (X) mode
 Exclusive (X) mode –
 If a transaction locks a data item and no other transaction can
access that item, even read until the lock is released by the
transaction.
 It is also called a write lock

 shared (S) mode

 If a transaction Ti has obtained a shared mode lock on item X
then Ti can read but can’t write data item X.
 It is also known as a Read-only lock. 
Lock-compatibility matrix

• General locking algorithm

1. Before using a data item x, transaction requests lock for x
from the lock manager
2. If x is already locked and the existing lock is incompatible
with the requested lock, the transaction is delayed
3. Otherwise, the lock is granted
 Example of a transaction performing locking:

T1 T2
LOCKX(A) LOCKX(SUM)
READ(A) A=1000 SUM:=0
A:=A-200 A=800 LOCKS(A)
WRITE(A) A=800 READ(A) A=800
UNLOCK(A) SUM:=SUM+A SUM=800
LOCKX(B) UNLOCK(A)
READ(B) B=900 LOCKS(B)
B:=B+200 B=1100 READ(B) B=1100
WRITE(B) B=1100 SUM:=SUM+B SUM=1900
UNLOCK(B) WRITE(SUM) SUM=1900
UNLOCK(B)
UNLOCK(SUM)
IF EXECUTED SERIALLY THE
OUTPUT WILL BE 1900
IF RUNNING CONCURREENTLY THEN SUM WILL BE 2100, LOSS
UPDATE
 T2:LOCKX(SUM)  T1:WRITE(B) B=1100
 T2:SUM:=0  T1:UNLOCK(B)
 T2:LOCKS(A) A=1000  T2:LOCKS(B)
 T2:READ(A)  T2:READ(B) B=1100
 T2:SUM:=SUM+A SUM=1000  T2:SUM:=SUM+B SUM=2100
 T2:UNLOCK(A)  T2:WRITE(SUM) SUM=2100
 T1:LOCKX(A)  T2:UNLOCK(B)
 T1:READ(A) A=1000  T2:UNLOCK(SUM)
 T1:A:=A-200 A=800
 AFTER TRANSACTION SUM+B IS
 T1:WRITE(A) A=800
 T1:UNLOCK(A) 2100 .This is inconsistent. This locking
 T1:LOCKX(B) technique didn’t solve this problem because
 T1:READ(B) B=900
value of a/c A was added to sum before
 T1:B:=B+200 B=1100
modification was performed
 Consider another example
 T1
 LOCKX(B)
 UNLOCK(A)
 READ(B) B=200  LOCKS(B)
 B:=B-50B=150
 WRITE(B) B=150  READ(B) B=150
 UNLOCK(B)
 LOCKX(A)  UNLOCK(B)
 READ(A) A=100
 A:=A+50 A=150
 DISPLAY(A+B)
 WRITE(A) A=150 A+B=300
 UNLOCK(A)
 T2:
 THIS IS CLEAR THAT IF
 LOCKS(A) THEY RUN SEQUENTIALLY
 READ(A) A=150 THE OUT PUT WILL BE 300
Now if we delay unlocking to the end of transaction then

T1 READ(A) A=150
LOCKX(B) LOCKS(B)
READ(B) B=200 READ(B) B=150
B:=B-50 B=150 UNLOCK(A)
WRITE(B) B=150 UNLOCK(B)
LOCKX(A) DISPLAY(A+B)
READ(A) A=100 HERE ALSO A+B WILL BE 300
A:=A+50A=150
WRITE(A) A=150
UNLOCK(B)
UNLOCK(A)
T2
LOCKS(A)
Two phase locking
 Phase 1: Growing Phase
 Transaction may obtain locks
 Transaction may not release locks
 Phase 2: Shrinking Phase
 Transaction may release locks
 Transaction may not obtain locks
 Example:
T1 T1
READ(B)
READ(B)
B:=B-50
B:=B-50 WRITE(B)
WRITE(B) LOCKX(A)
UNLOCK(B) READ(A)
A:=A+50
LOCKX(A)
WRITE(A)
READ(A) UNLOCK(B)
A:=A+50 UNLOCK(A)
WRITE(A)
UNLOCK(A) This is 2 phase because unlocks
This is not 2 phase because unlock(b) appears appears after all lock operation
before lock(a)
 Two-phase locking does not ensure freedom from deadlocks
 Cascading roll-back is possible under two-phase locking.
 To avoid this, follow a modified protocol called strict two-phase
locking. Here a transaction must hold all its exclusive locks till it
commits/ aborts.
 This requirement ensures that any data written by uncommitted
transaction are locked in exclusive mode until the transaction commits.

 preventing any other transaction from reading the data.

Strict Two-Phase Locking
 Strict-Two phase locking system is almost similar to 2PL.
 The only difference is that Strict-2PL never releases a lock after using
it. It holds all the locks until the commit point.
 Centralized 2PL
 A single site is responsible for lock management process.
 It has only one lock manager for the entire DBMS.
 Primary copy 2PL
 Many lock managers are distributed to different sites.
 Lock manager is responsible for managing the lock for a set of data items.
 Distributed 2PL
 Lock managers are distributed to all sites.
 If no data is replicated, it is equivalent to primary copy 2PL.
 They are responsible for managing locks for data at that site.
 Conversion of locks
 A mechanism is provided for upgrading a shared lock to exclusive
lock and downgrading an exclusive lock to a shared lock.
 Conversion from shared to exclusive modes is denoted by
upgrade
 Conversion from exclusive to shared mode by downgrade.
 Lock conversion is not allowed to occur arbitrarily.
 Upgrading takes place only in growing phase whereas
downgrading takes place in only shrinking phase
Implementation of Locking
 A Lock manager can be implemented as a separate process to which
transactions send lock and unlock requests.
 The lock manager replies to a lock request by sending a lock grant
messages (or a message asking the transaction to roll back, in case of a
deadlock).
 The requesting transaction waits until its request is answered
 The lock manager maintains a data structure called a lock table to record
granted locks and pending requests.
 Lock Table

 New request is added to the end of the

queue of requests for the data item, and
granted if it is compatible with all earlier
locks.
 Unlock requests result in the request
being deleted, and later requests are
checked to see if they can now be granted
 If transaction aborts, all waiting or
Black rectangles indicate granted granted requests of the transaction are

locks, white ones indicate waiting deleted

requests.  Lock manager may keep a list of locks

held by each transaction, to implement
Lock table also records the type of
this efficiently
lock granted or requested
Pitfalls of Lock-Based Protocols
 Deadlocks
 Starvations
 Deadlock occurs when two or more transactions are waiting on a
condition that cannot be satisfied.
 Deadlock can arise if the following 4 conditions hold simultaneously in a system ;
 Mutual exclusion: At least one resource is held in a non-sharable mode.
 Exclusive lock request.
 Hold and wait: There is a transaction which acquired and held lock on a data
item, and waits for other data item.
 No preemption:  situation where a transaction releases the locks on data items
which it holds only after the successful completion of the transaction.
 Circular wait: A situation where a transaction T1 is waiting for another
transaction T2 to release lock on some data items, in turn T2 is waiting for
another transaction T3 to release lock, and so on.
Deadlock Prevention
 We can prevent Deadlock by eliminating any of the above four
conditions.
 Wait-Die Scheme
 Wound Wait Scheme
 Deadlock Avoidance
 Deadlock avoidance can be done with Banker’s Algorithm.
Pitfalls of Lock-Based Protocols (Cont.)

 Starvation:  occurs when one or more transactions in a program are

blocked from gaining access to a resource and, as a result, cannot make
progress. 
 Starvation is also possible if concurrency control manager is badly
designed.

 Avoiding starvation:
Example

Consider the partial schedule

Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to

wait for T3 to release its lock on B, while executing lock-X(A) causes T3 to

wait for T4 to release its lock on A.

Such a situation is called a deadlock.

 To handle a deadlock one of T3 or T4 must be rolled back and its locks released.
Timestamp-based Protocols
 The timestamp-based algorithm uses a timestamp to serialize
the execution of concurrent transactions.
 This protocol ensures that every conflicting read and write
operations are executed in timestamp order.
 The protocol uses the System Time or Logical Count as a
Timestamp.
 The older transaction is always given priority in this method. 
Timestamp-based Protocols
 Advantages:
 Schedules are serializable just like 2PL protocols
 No waiting for the transaction, which eliminates the possibility
of deadlocks!
 Disadvantages:
 Starvation is possible if the same transaction is restarted and
continually aborted
Validation Based Protocol
 Validation Based Protocol is also called Optimistic Concurrency Control
Technique.
 Read Phase:
Values of committed data items from the database can be read by a
transaction. Updates are only applied to local data versions.
 Validation Phase:
Checking is performed to make sure that there is no violation of
serializability when the transaction updates are applied to database.
 Write Phase:
On the success of validation phase, the transaction updates are applied to the
database, otherwise, the updates are discarded and the transaction is slowed
down.
Insert and Delete Operations
 If two-phase locking is used :
 A delete operation may be performed only if the transaction deleting the tuple
has an exclusive lock on the tuple to be deleted.
 A transaction that inserts a new tuple into the database is given an X-mode lock
on the tuple.
 Insertions and deletions can lead to the phantom phenomenon.
 A transaction that scans a relation (e.g., find all accounts in Perryridge) and a
transaction that inserts a tuple in the relation (e.g., insert a new account at
Perryridge) may conflict in spite of not accessing any tuple in common.
 If only tuple locks are used, non-serializable schedules can result: the scan
transaction may not see the new account, yet may be serialized before the insert
transaction.
Insert and Delete Operations
 The transaction scanning the relation is reading information that indicates what
tuples the relation contains, while a transaction inserting a tuple updates the same
information.
 The information should be locked.
 One solution:
 Associate a data item with the relation, to represent the information about what
tuples the relation contains.
 Transactions scanning the relation acquire a shared lock in the data item,
 Transactions inserting or deleting a tuple acquire an exclusive lock on the data
item. (Note: locks on the data item do not conflict with locks on individual
tuples.)