Recoverability of Schedule

• Sometimes a transaction may not execute

completely due to a software issue, system
crash or hardware failure.
• In that case, the failed transaction has to be
rollback.
• But some other transaction may also have
used value produced by the failed transaction.
So we also have to rollback those transactions.
• Table 1 shows a schedule which has two transactions.
• T1 reads and writes the value of A and that value is read and written by T2.
• T2 commits but later on, T1 fails.
• Due to the failure, we have to rollback T1.
• T2 should also be rollback because it reads the value written by T1, but T2 can't
be rollback because it already committed.
• So this type of schedule is known as irrecoverable schedule.
• Irrecoverable schedule: The
schedule will be irrecoverable if Tj
reads the updated value of Ti and Tj
committed before Ti commit.
• The above table 2 shows a schedule with two transactions.
• Transaction T1 reads and writes A, and that value is read and written by
transaction T2. But later on, T1 fails.
• Due to this, we have to rollback T1.
• T2 should be rollback because T2 has read the value written by T1.
• As it has not committed before T1 commits so we can rollback transaction
T2 as well.
• So it is recoverable with cascade rollback.
• Recoverable with cascading rollback: The schedule will be recoverable with
cascading rollback if Tj reads the updated value of Ti. Commit of Tj is
delayed till commit of Ti.
 Cascade less recoverable
schedule.

• The above Table 3 shows a schedule with two transactions.

Transaction T1 reads and write A and commits, and that value
is read and written by T2.
• So this is a cascade less recoverable schedule.
Schedule Based on Recoverability
 Recoverable Schedule:
• A schedule is recoverable if it allows for the recovery of the database to a
consistent state after a transaction failure.
• In a recoverable schedule, a transaction that has updated the database must
commit before any other transaction reads or writes the same data.
• If a transaction fails before committing, its updates must be rolled back, and any
transactions that have read its uncommitted data must also be rolled back.
 Cascadeless Schedule
• A schedule is cascaded less if it does not result in a cascading rollback of
transactions after a failure.
• In a cascade-less schedule, a transaction that has read uncommitted data
from another transaction cannot commit before that transaction commits.
• If a transaction fails before committing, its updates must be rolled back,
but any transactions that have read its uncommitted data need not be
rolled back
 Strict Schedule
• If the schedule contains no read or write before commit then it is known as a strict
schedule. A strict schedule is strict in nature.
• A schedule is strict if for any two transactions T i , T j , if a write operation of T i
precedes a conflicting operation of T j (either read or write),
• Then the commit or abort event of T i also precedes that conflicting operation of
Tj
• In other words, T j can read or write updated or written value of T i only after T i
commits/aborts.
Relation between various types of
schedules
Summary: Type of Schedule
Concurrency Control
• Whenever multiple transactions are working
on same database concurrently, it may leads
to data in consistency.
• Let us consider this scenario:

T1 T2

X
X √ X
 T1 W T1

A R

X R
B T2
W
T2 Database R

T3

▪ Multiple Transactions may allowed to read operation simultaneously.

▪ But only one Transaction should perform write operation at a time.
• We need to control concurrent execution of
transactions. We need to make them
Serilazible.
• One method is to Lock the Data item accessed
by transaction until transaction is completed.
This ensures serializability.
• Another method is to Assign some Time
Stamps and compare the Time stamps. This
ensures serializability.
•
• Locking. Time Stamps

T1 T2 T1 (Start Time=2)

X
A X A
√ TS = 3
A

T2 (Start Time=4)
 Lock-Based Protocols
• 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.
• Lock requests are made to concurrency-control
manager. Transaction can proceed only after
request is granted.
•
Lock-Based
Lock-compatibility matrix
Protocols (Cont.)

• A transaction may be granted a lock on an item if the requested lock is

compatible with locks already held on the item by other transactions.

• Any number of transactions can hold shared locks on an item,

• But if any transaction holds an exclusive on the item no other

transaction may hold any lock on the item.

• If a lock cannot be granted, the requesting transaction is made to wait

till all incompatible locks held by other transactions have been
released. The lock is then granted.
 Lock-Based Protocol
1. Shared lock:
•It is also known as a Read-only lock. In a shared lock, the data
item can only read by the transaction.
•It can be shared between the transactions because when the
transaction holds a lock, then it can't update the data on the data
item.
2. Exclusive lock:
•In the exclusive lock, the data item can be both reads as well as
written by the transaction.
•This lock is exclusive, and in this lock, multiple transactions do
not modify the same data simultaneously.
Scenario: Lock-Based Protocol
 Lock Manager (Lock Request and Unlock)

1: Requests
Concurrency Control Component T1
4: Granted/ Denied

2: Check 3: T/F

Lock Compatibility Table

• Examples:

T1 T2 T1 T2
Lock-S (A)
Lock-S (A)
Read (A)
Read (A)
Lock-X(A)
Lock-S(A) Read (P)

Read (P) P=P+10

Write (P)
Unlock (A)
Unlock (A)
Unlock (A) Unlock (A)

Possible Not Possible

 Locking Protocols
• A locking protocol is a set of rules followed by all
transactions while requesting and releasing locks.
Locking protocols restrict the set of possible schedules.

• Simple Locking.

• 2 Phase Locking.
– Basic 2 Phase Locking (B2PL)
– Conservative 2 Phase Locking (C2PL)
– Strict 2 Phase Locking(S2PL)
– Rigorous 2 Phase Locking (R2PL)
 Simple Locking
• Lock The Data Item before access.
• Release the Lock as soon as action is Over.
• Example:
1. Lock –X (A)
2. Read (A)
3. A=A+10
4. Write (A)
5. Unlock (A)
• When the Transaction executes serially, no issue.
• But when executed in interleaved manner may leads to inconsistent.

100 T2: Display (A+B)

T1: (A B)
Lock –X (A) Lock-S (A)
R(A)
R(A)
A=A-100;
W(A) Unlock (A)
Unlock(A)
Lock-X(B) Lock-S(B)

R(B)
R(B)
B=B+100
W(B) Unlock(B)

W(B)
Display (A +B)
Unlock (B)
 T1 T2
Lock –X (A)
R(A)
A=A-100;
W(A)
Unlock(A) Lock-S (A)

R(A)
Unlock (A)

Lock-X(B)
R(B)
B=B+100
W(B)
Unlock (B) Lock-S(B)

R(B)
Unlock(B)
Display (A +B)
 Pitfalls of Lock-Based Protocols (Cont.)

• The potential for deadlock exists in most locking

protocols. Deadlocks are a necessary evil.
• Starvation is also possible if 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 granted an S-lock on the same item.
– The same transaction is repeatedly rolled back due to
deadlocks.
• Concurrency control manager can be designed to
prevent starvation.
 The Two-Phase Locking Protocol
• This is a protocol which ensures conflict-
serializable schedules.
• 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
• The protocol assures serializability. It can be
proved that the transactions can be serialized in
the order of their lock points (i.e. the point
where a transaction acquired its final lock).
 Simple 2 Phase Locking Protocol

Lock Point
Unlock
R/W Lock
R/W
Locks Acquired Locks Released
Unlock
Lock

Growing Phase Shrinking Phase

Start Transaction End Transaction
• Basic 2 Phase Locking Protocol Disadvantages:
– Unnecessary wait due to early access
– Deadlock
– Cascading rollback
• Unnecessary wait due to early access
T1 T2
Lock-X(A)
R(A)
Growing Phase
W(A)
Lock-X(B)
R(B)
. Lock-S(A): has to wait:
.
.
• Deadlock:
T1 T2
Lock-X(B)
R(B)
W(B)
Lock-S(A)
R(A)
Lock-X(B)
Lock-X(A)

T1 B

A T2
• Cascading Rollback:
T1 T2 T3
Lock-X (A)
R(A)
Rollback
W(A)
U(A) Rollback
. Lock-X(A)
Rollback
. R(A)
Failure W(A)
U(A)
Lock-X(A)
R(A)
. . .
. . .
. . .
Conservative 2 Phase Locking Protocol
• Lock the Data items before Transaction Starts.
• Need early predictions of how many data
items may be required for transaction.
– T1 : [A B C D]
– Request Lock on { A B C D}
– If lock is granted operation starts.
– Otherwise it will wait further the request to be
granted.
Conservative 2 Phase Locking Protocol

All Locks Granted Lock Point Start Transaction

Unlock
No Growing Phase
R/W
Locks Released
Unlock
Shrinking Phase
End Transaction
• Deadlock Never Occur.
• Early Prediction is difficult for practical
implementation.
• Cascading Rollback may present.
 Strict Phase Locking Protocol
• Transaction does not release any of its lock Exclusive
Lock until it is committed/Aborted.
Lock Point
Unlock-S
Lock-X
R/W
Locks Acquired Locks Released
Lock-S End Transaction
Committed
Growing Phase Shrinking Phase
Unlock-X
• S2PL is Most Popular.
• Does not have cascading roll back.
• Deadlock May Present.
• Generates Strict Schedule.(Both Recoverable
and Cascade less.
• Easy Recovery.
 Recoverable Schedule
• For each pair of transactions (Ti, Ti), if Tj reads the
item that was previously written by Ti, then commit
operation of Ti should appear before commit
operation Tj.
T1 T2
R1(A)
A= A+150
W(A)
R2(A)
A= A-50;
W2(A)
Commit;
Commit;
 Strict Schedule
• If a value written by a transaction cannot be
read or over written by another transaction
until the transactions is either aborted or
committed.
• Every Strict Schedule is Recoverable and
Cascade less. T1 T2
R1 (A)
W1(A)
Commit;
W2(A)
R(A)
 Rigorous Phase Locking Protocol
• Transaction does not release any of its Lock (Shared
and Exclusive) until it is committed or Aborted.
Lock Point End Transaction
Committed
R/W Lock-X
Unlock-S
Locks Acquired
Unlock-X
Lock-S
Start Transaction
No Shrinking Phase
Growing Phase
• Does not have cascading roll back.
• Deadlock May Present.
 C2PL
B2PL
Lock Point
Unlock-S
Lock-X
R/W
Locks Acquired Locks Released
Lock-S End Transaction
Committed
Growing Shrinking Phase
S2PL Unlock-X
Phase
R2PL
 Examples
T1

Lock-S(A) B2PL

R(A) C2PL

Lock-X(B) S2PL
R(A)
R2PL
R(B)

B=A+B

Unlock(A)

W(B)

Unlock(B)
 T1

Lock-S(A)

R(A)
B2PL
Lock-X(B)
C2PL

Unlock(A) S2PL

R(B) R2PL

W(B)

Commit

Unlock(B)
 T1
B2PL
Lock-S(A)
C2PL
R(A)
S2PL
Unlock(A)
R2PL
Lock-X(B)

R(B)

W(B)

Unlock(B)

Commit
 Write Schedules Using B2PL
• Transaction 1: T1
Lock –S (A)
– Read (A)
R(A)
– Read (B) Lock –X (B)
– If A=0, B=B+1; R(B)
If A=0; B=B+1;
– Write (B); Unlock (A)
W(B)
Unlock(B)
 Write Schedules Using C2PL
• Transaction 1: T1

– Read (A) Lock –S (A), Lock –X(B)

– Read (B) R(A)

R(B)
– If A=0, B=B+1;
If A=0; B=B+1;
– Write (B);
Unlock (A)

W(B)

Unlock(B)
 Write Schedules Using S2PL
• Transaction 1: T1
Lock –S (A),
– Read (A)
R(A)
– Read (B) Lock –X(B)
– If A=0, B=B+1; R(B)
If A=0; B=B+1;
– Write (B); Unlock (A)
W(B)
Commit
Unlock(B)
 Write Schedules Using R2PL
• Transaction 1: T1
Lock –S (A),
– Read (A)
R(A)
– Read (B) Lock –X(B)
– If A=0, B=B+1; R(B)
If A=0; B=B+1;
– Write (B); W(B)
Commit
Unlock(B)
Unlock (A)
 Solve This
• Transaction 2:
– Read (B)
– Read (A)
– If B=0, A =A-B
– Write(A)

• Find Schedules using: B2PL, C2PL, S2PL and

R2PL.
 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
• The lock table is usually implemented as an in-memory
hash table indexed on the name of the data item being
locked
Lock Table
• Black rectangles indicate granted
locks, white ones indicate waiting
requests
• Lock table also records the type of
lock granted or requested
• 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
Granted can now be granted
Waiting • If transaction aborts, all waiting or
granted requests of the transaction
are deleted
– lock manager may keep a list of
locks held by each transaction,
to implement this efficiently