This document outlines different concurrency control protocols used to ensure serializability of transactions in a database. It discusses lock-based protocols like two-phase locking and tree protocols. It also covers timestamp-based protocols that assign timestamps to transactions and validate reads/writes based on timestamp order. Validation-based protocols execute transactions optimistically and validate during a separate validation phase if updates can be committed without violating serializability.

1. Prepared by :
AbdelrahmanAlmassry
supervision :
Dr.Suhair Harb

2. Outline :
•Lock-Based Protocols
•Timestamp-Based Protocols
•Validation-Based Protocols
•MultipleGranularity

3. Need for concurrent control
• In case of concurrent execution of several transaction in the Database,
the consistency of the data may no longer be maintained.
• It is necessary for the system to control the interaction among the
concurrent transactions, and this control is achieved through one of a
variety of mechanisms called concurrent-control schemes.
• To ensure serializability, we can use various concurrency-control
schemes. All these schemes either delay an operation of abort a
transaction that issued the operation.

4. Lock-Based Protocols
• While one transaction is accessing a data item, no other transaction
can modify that data item.
• The most common method used to implemented this requirement is
to allow a transaction to access a data item only if it is concurrently
holding a lock on that item.

5. Lock-Based Protocols(cont.)
• A lock is a mechanism to control concurrent access to a data
item
• Data items can be locked in two modes :
1. exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2. shared (S) mode. Data item can only be read. S-lock is
requested using lock-S instruction.

6. Lock-Based Protocols(cont.)
• Lock-compatibility matrix • Example of a transaction
performing locking:
T2:
lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)

7. Risks of Lock-Based Protocols
1. Deadlocks
T3 T4
Lock-X(B)
Read(B)
B := B – 50
Write (B)
Lock-S(A)
Read(A)
Lock-S(B)
Lock-X(A)
T3 T4

8. Risks of Lock-Based Protocols
1. Deadlocks
T3 T4
Lock-X(B)
Read(B)
B := B – 50
Write (B)
Lock-S(A)
Read(A)
Lock-S(B)
Lock-X(A)
T3 T4
A
B

9. Risks of Lock-Based Protocols
1. Deadlocks
T3 T4
Lock-X(B)
Read(B)
B := B – 50
Write (B)
Lock-S(A)
Read(A)
Lock-S(B)
Lock-X(A)
T3 T4
A
B

10. Risks of Lock-Based Protocols
2. Starvation
• Is also possible if the concurrency-control manager is badly designed.
For example :
• A transaction may be waiting for an X-lock on an item, while a sequence of
other transactions request and are generated an S-lock on the same item.
• The same transaction is repeatedly rolled back due to deadlocks.

11. Types of Lock-Based Protocols
• It requires that each transaction issues lock and unlock requests
in two Phases :
• 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.
1.TheTwo-Phase locking Protocol

12. TheTwo-Phase Locking Protocol
T1 T2
Lock-X (A)
Growing Phase

13. TheTwo-Phase Locking Protocol
T1 T2
Lock-X (A)
Lock-X (B)
Lock-S (C)
Growing Phase

14. TheTwo-Phase Locking Protocol
T1 T2
Lock-X (A)
Lock-X (B)
Lock-S (C)
Unlock (A)
Growing Phase
Shrinking Phase

15. TheTwo-Phase Locking Protocol
T1 T2
Lock-X (A)
Lock-X (B)
Lock-S (C)
Unlock (A)
Loch-S (D)
Growing Phase
Shrinking Phase

16. TheTwo-Phase Locking Protocol
T1 T2
Lock-X (A)
Lock-X (B)
Lock-S (C)
Unlock (A)
Loch-S (D)
Growing Phase
Shrinking Phase

17. TheTwo-Phase Locking Protocol
T1 T2
Lock-X (A)
Lock-X (B)
Lock-S (C)
Unlock (A)
Loch-S (D)
Lock-X (A)
Unlock (C)
Lock-X (C)
Growing Phase
Shrinking Phase

18. Lock Conversions
• Two-phase locking with lock conversions :
• First phase :
• Can acquire a lock-S on item
• Can acquire a lock-X on item
• Can convert a lock-S to a lock-X (upgrade)
• Second phase
• Can acquire a lock-S on item
• Can acquire a lock-X on item
• Can convert a lock-X to a lock-S (downgrade)

19. Automatic Acquisition of Locks
• A transaction Ti issues the standard read/write instruction, without
explicit locking calls.
• The operation read(D) is processed as:
if Ti has a lock on D
then
read(D)
else begin
if necessary wait until no other
transaction has a lock-X on D
grant Ti a lock-S on D;
read(D)
end

20. Automatic Acquisition of Locks(Cont.)
• write(D) is processed as:
if Ti has a lock-X on D
then
write(D)
else begin
if necessary wait until no other trans. has any lock on D,
if Ti has a lock-S on D
then
upgrade lock on D to lock-X
else
grant Ti a lock-X on D
write(D)
end;
• All locks are released after commit or abort

21. 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

22. Implementation of Locking

23. Types of Lock-Based Protocols
• Graph-based protocols are an alternative to two-phase locking
• Impose a partial ordering  on the set D = {d1, d2 ,..., dh} of all data
items.
• If di  dj then any transaction accessing both di and dj must access di before
accessing dj.
• Implies that the set D may now be viewed as a directed acyclic graph, called a
database graph.
• The tree-protocol is a simple kind of graph protocol.
2. Graph-based Locking Protocol

24. Tree Protocol
• Rule 1 : Only exclusive locks are allowed.
• Rule 2 :The first lock by Ti may be on any data item. Subsequently, a data Q
can be locked by Ti only if the parent of Q is currently locked by Ti.
• Rule 3 : Data items may be unlocked at any time.
• Rule 4 :A data item that has been locked and unlocked by Ti cannot
subsequently be relocked by Ti

25. Tree Protocol

26. Timestamp-Based Protocols
• Each transaction is issued a timestamp when it enters the
system. If an old transaction Ti has time-stampTS(Ti), a new
transaction Tj is assigned time-stampTS(Tj) such thatTS(Ti)
<TS(Tj).
• When happened conflict we sorted the transaction at the first
execution time by the first lock request.
• There are another method for determining the serializability, we
sorted the transaction when entered the system before execution.
• The most common method for doing so it to use tampstamp ordering schemes.

27. Timestamp-Based Protocols(Cont.)
• There are two simple methods to implement this scheme
• Use the value of system clock as the timestamp.
• Use a logical counter that is incremented after a new timestamp has been assigned.
• In order to assure such behavior, the protocol maintains for each data
Q two timestamp values:
• W-timestamp(Q) is the largest time-stamp of any transaction that executed
write(Q) successfully.
• R-timestamp(Q) is the largest time-stamp of any transaction that executed
read(Q) successfully.

28. Timestamp-Based Protocols
• The timestamp ordering protocol ensures that any
conflicting read and write operations are executed in
timestamp order.
• Suppose a transactionTi issues a read(Q)
1. IfTS(Ti)  W-timestamp(Q), then Ti needs to read a value of Q that was
already overwritten.
 Hence, the read operation is rejected, and Ti is rolled back.
2. IfTS(Ti) W-timestamp(Q), then the read operation is executed, and R-
timestamp(Q) is set to max(R-timestamp(Q),TS(Ti)).

29. Timestamp-Based Protocols(Cont.)
• Suppose that transaction Ti issues write(Q).
1. IfTS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was needed
previously, and the system assumed that that value would never be produced.
 Hence, the write operation is rejected, and Ti is rolled back.
2. IfTS(Ti) <W-timestamp(Q), then Ti is attempting to write an obsolete value of
Q.
 Hence, this write operation is rejected, and Ti is rolled back.
3. Otherwise, the write operation is executed, andW-timestamp(Q) is set to
TS(Ti).
• If a transaction Ti is rolled back by the concurrency control scheme as
result of wrong distribution of either a read or write operation, the
system assigns the transaction Ti a new timestamp and restarts it.

30. Example Use of the Protocol

31. Recoverability and Cascade Freedom
• Problem with timestamp-ordering protocol:
• Suppose Ti aborts, but Tj has read a data item written by Ti
• Then Tj must abort; if Tj had been allowed to commit earlier, the schedule is not
recoverable.
• Further, any transaction that has read a data item written by Tj must abort
• This can lead to cascading rollback --- that is, a chain of rollbacks
• Solution :
• A transaction is structured such that its writes are all performed at the end of
its processing
• All writes of a transaction form an atomic action; no transaction may execute
while a transaction is being written
• A transaction that aborts is restarted with a new timestamp

32. Thomas’ Write Rule
• Modified version of the timestamp-ordering protocol in which
obsolete write operations may be ignored under certain
circumstances.
• When Ti attempts to write data item Q, ifTS(Ti) <W-timestamp(Q),
then Ti is attempting to write an obsolete value of {Q}.
• Rather than rolling back Ti as the timestamp ordering protocol would have
done, this {write} operation can be ignored.
• Otherwise this protocol is the same as the timestamp ordering
protocol.
• Thomas'Write Rule allows greater potential concurrency.
• Allows some view-serializable schedules that are not conflict-serializable.

33. Validation-Based Protocol
• Execution of transaction Ti is done in three phases.
1. Read and execution phase:Transaction Ti writes only to
temporary local variables
2. Validation phase:Transaction Ti performs a ``validation test''
to determine if local variables can be written without violating
serializability.
3. Write phase: If Ti is validated, the updates are applied to the
database; otherwise,Ti is rolled back.
• The three phases of concurrently executing transactions can be interleaved, but
each transaction must go through the three phases in that order.
• Assume for simplicity that the validation and write phase occur together, atomically and
serially
• I.e., only one transaction executes validation/write at a time.
• Also called as optimistic concurrency control since transaction executes fully in the
hope that all will go well during validation

34. Validation-Based Protocol(cont.)
• Each transactionTi has 3 timestamps
• Start(Ti) : the time whenTi started its execution
• Validation(Ti): the time whenTi entered its validation phase
• Finish(Ti) : the time whenTi finished its write phase
• Serializability order is determined by timestamp given at validation
time, to increase concurrency.
• ThusTS(Ti) is given the value ofValidation(Ti).
• This protocol is useful and gives greater degree of concurrency if
probability of conflicts is low.
• because the serializability order is not pre-decided, and relatively few
transactions will have to be rolled back.

35. Validation Test forTransactionTj
• If for all Ti withTS (Ti) <TS (Tj) either one of the following condition
holds:
• finish(Ti) < start(Tj)
• start(Tj) < finish(Ti) < validation(Tj) and the set of data items written by Ti does
not intersect with the set of data items read by Tj.
then validation succeeds and Tj can be committed. Otherwise,
validation fails and Tj is aborted.

36. Schedule Produced byValidation

37. Multiple Granularity
Field 2 Field 3 Field 4
Row 1
Row 2
Row 3
Row 4
File
File(Table)
Area(set of Files)
DataBase
Field 2 Field 3 Field 4
Row 1
Row 2
Row 3
Row 4

38. Example of Granularity Hierarchy(tree)
The levels, starting from the coarsest (top) level are
database
area
file
record
fine granularity
coarse granularity

39. Intention Lock Modes
• In addition to S and X lock modes, there are three additional lock
modes with multiple granularity:
• intention-shared (IS): indicates explicit locking at a lower level of the tree but
only with shared locks.
• intention-exclusive (IX): indicates explicit locking at a lower level with exclusive
or shared locks
• shared and intention-exclusive (SIX): the subtree rooted by that node is locked
explicitly in shared mode and explicit locking is being done at a lower level with
exclusive-mode locks.
• intention locks allow a higher level node to be locked in S or X mode
without having to check all descendent nodes.

40. Compatibility Matrix with Intention Lock Modes