RECOVERABILITY

UNIT - IV TRANSACTIONS
RECOVERABLE SCHEDULES

A recoverable schedule is one where,

for each pair of transactions Ti and Tj such
that Tj reads a data item previously written
by Ti , the commit operation of Ti appears
before the commit operation of Tj .

The schedules that do not meet this

criteria are called non recoverable
schedules.
RECOVERABLE SCHEDULES
S
T1 T2
R(X)
W(X)
R(X)
R(Y)
W(X)
COMMIT
ABORT

S 🡪 NON RECOVERABLE SCHEDULE

RECOVERABLE SCHEDULES
S
T1 T2
R(X)
W(X)
R(X)
R(Y)
W(X)
W(Y)
COMMIT
COMMIT
S 🡪RECOVERABLE SCHEDULE
CASCADELESS SCHEDULES
• A single transaction failure leading to a series of
transaction rollbacks, is called cascading rollback.

T9 reads value T10 reads value

written by T8, written by T9, so
so abort abort
CASCADELESS SCHEDULES

• A cascadeless schedule is one where, for each pair of

transactions Ti and Tj such that Tj reads a data item
previously written by Ti , the commit operation of Ti
appears before the read operation of Tj .
• Every cascadeless schedule is recoverable.
STRICT SCHEDULES

Strict schedule is a schedule, in which

transactions can neither read nor write an item X until
the last transaction that wrote X has committed (or
aborted)
 LOCKING

UNIT - IV TRANSACTIONS
LOCKING

• A lock is a variable associated with a data item that

describes the status of the item with respect to
possible operations that can be applied to it.

• Locks are used as a means of synchronizing the access

by concurrent transactions to the database items.
LOCK MODES
• Shared
If a transaction Ti has obtained a shared-mode lock

(denoted by S) on item Q, then Ti can read, but cannot

write Q.
• Exclusive
If a transaction Ti has obtained an exclusive-mode

lock (denoted by X) on item Q, then Ti can both read

OPERATIONS

• lock_item

• unlock_item
RULES

1. A transaction T must issue the operation

lock_item(X) before any read_item(X) or
write_item(X) operations are performed in T.

2. A transaction T must issue the operation

unlock_item(X) after all read_item(X) and
write_item(X) operations are completed in T.
RULES

3. A transaction T will not issue a lock_item(X)

operation if it already holds the lock on item X.

4. A transaction T will not issue an unlock_item(X)

operation unless it already holds the lock on item X.
Locks
T
lock-x(A)
read(A)
A:=A-100
write(A)
unlock(A)
lock-x(B)
read(B)
B:=B+100
write(B)
unlock(B)
Locks

• The transaction makes the request to the concurrency-control

manager.
• The transaction can proceed with the operation only after the
concurrency-control manager grants the lock to the
transaction.
• The use of these two lock modes allows multiple transactions
to read a data item but limits write access to just one
transaction at a time.
Locks

The state in which every transaction in the

transaction set is waiting for another transaction
in the set is known as deadlock.
If a transaction is not able to access a data item,
continuously waits for a lock and never make any
progress, it is said to be starved.
Conversion of Locks

Upgrading:
Conversion from read-lock(X) to write-lock(X)

Downgrading:
Conversion from write-lock(X) to read-lock(X)
Locking Protocol

Transaction may lock and unlock each of the data

items during its execution. Locking protocol indicates
when a transaction may lock and unlock each of the
data items.
Two-phase Locking Protocol
Phases
1. Growing Phase
T obtain locks, may not release any locks
2. Shrinking Phase
T may release locks, may not obtain any new locks
• Initially, a transaction is in the growing phase. The
transaction acquires locks as needed.
• Once the transaction releases a lock, it enters the shrinking
phase, and it can issue no more lock requests.
Two-phase Locking Protocol

• The two-phase locking protocol ensures conflict

serializability.
• The point in the schedule where the transaction has obtained
its final lock (the end of its growing phase) is called the lock
point of the transaction.
Two-phase Locking Protocol

T1 T2
lock-s(A) //Shared lock on A
read(A)
lock-s(B) // Shared lock on B
read(B)
lock-s(A) // Shared lock on A

read(A)
//releasing lock on A
unlock(A)
unlock(A) //releasing lock on A
//releasing lock on B
unlock(B)
Two-phase Locking Protocol

T1 T2
lock-x(A) // Exclusive lock on A

read(A)
lock-s(A) //Requesting Read lock
on A, not granted
write(A)
//releasing lock on A
unlock(A)
lock-s(A) //Shared lock on A

read(A)
unlock(A) //releasing lock on A

commit
commit
Two-phase Locking Protocol
Consider two transactions T1, T2

T1 T2
R(A)
W(A)
R(A)
W(A)
R(B)
W(B)
R(B)
W(B)
commit
commit
Two-phase Locking Protocol

• If T1 aborts, T2 also aborts

• Cascading rollback occurs.

(A single transaction failure leading to a series of
transaction rollbacks, is called cascading rollback.)
Strict Two-phase Locking Protocol

• Cascading rollbacks can be avoided by a

modification of two-phase locking called the strict
two-phase locking protocol.

• All exclusive locks must be unlocked after commit

• Ensures serializable schedule
Rigorous Two-phase Locking Protocol

• All locks must be hold until commit

 TIMESTAMP BASED
PROTOCOL

UNIT - IV TRANSACTIONS
TIMESTAMP

• Timestamp is an information identifying when a

certain event occurred, usually giving date and time of

day, sometimes accurate to a small fraction of a

second.
TIMESTAMP

• Consider a Transaction, Ti with a Timestamp, TS(Ti)

in the system

• If a new Transaction, Tj with a Timestamp TS(Tj)

enters the systems, then

TS(Ti) < TS(Tj)

Implementing Timestamp

• Use the value of the system clock as timestamp

• Use a logical counter that is incremented after a

new timestamp has been assigned

Implementing Timestamp

• The timestamps of the transactions determine the

serializability order.

• If TS(Ti) < TS(Tj), then the system must ensure

that the produced schedule is equivalent to a serial

schedule in which transaction Ti appears before

Timestamp values on data item

• W-timestamp(X)
largest timestamp of any transaction that executed
write(Q) successfully

• R-timestamp(X)
largest timestamp of any transaction that executed
read(Q) successfully.
TIMESTAMP-ORDERING PROTOCOL

The timestamp-ordering protocol ensures that any

conflicting read and write operations are executed in
timestamp order.
TIMESTAMP-ORDERING PROTOCOL

Operation:
1.Suppose that transaction Ti issues read(X)

a. If TS(Ti ) < W-timestamp(X),

read operation is rejected, and Ti is rolled back
b. Otherwise,
read operation is executed,
R-timestamp(X) is set to the maximum of
TIMESTAMP-ORDERING PROTOCOL

2.Suppose that transaction Ti issues write(X)

a. If TS(Ti) < R-timestamp(X),

rejects the write operation and rolls Ti back.
b. If TS(Ti) < W-timestamp(Q),
rejects the write operation and rolls Ti back.
c.Otherwise,
executes the write operation and sets
 TIMESTAMP-ORDERING PROTOCOL

T1 T2

R(X)
TS of T1:1
TS of T2:2 W(X)
R(X)
 TIMESTAMP-ORDERING PROTOCOL

T1 T2 R-timestamp(X) :0
W-timestamp(X) :0
TS of T1:1 R(X)
TS of T2:2 W(X)
R(X)

• T1 issues R(X)
• TS-T1 is 1
• TS-T2 >W-timestamp(X), Read(X) is allowed
• R-timestamp is set to 1
 TIMESTAMP-ORDERING PROTOCOL

T1 T2 R-timestamp(X) :1
TS of T1:1 R(X) W-timestamp(X) :0
TS of T2:2 W(X)
R(X)

• T2 issues W(X)
• TS-T2 is 2
• TS-T2 >R-timestamp(X), Write(X) is allowed
• W-timestamp is set to 2
 TIMESTAMP-ORDERING PROTOCOL

T1 T2 R-timestamp(X) :1
TS of T1:1 R(X) W-timestamp(X) :2
TS of T2:2 W(X)
R(X)

• T1 issues R(X)
• TS-T1 is 1
• TS-T1 <W-timestamp(X), Read(X) is allowed
• Rollback T1
 Thomas’s Write Rule

T1 T2 R-timestamp(X) :1
TS of T1:1 R(X) W-timestamp(X) :2
TS of T2:2 W(X)
R(X)

• T1 issues R(X)
• TS-T1 is 1
• TS-T1 <W-timestamp(X), Read(X) is allowed
• Rollback T1
 Thomas’s Write Rule

Suppose that transaction Ti issues write(Q).

• If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is
producing was previously needed, and it had been assumed that
the value would never be produced. Hence, the system rejects
the write operation and rolls Ti back.
• If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an
obsolete value of Q. Hence, this write operation can be ignored.
(No rollback)
• Otherwise, the system executes the write operation and sets
W-timestamp(Q) to TS(Ti ).
 DEADLOCK

UNIT - IV TRANSACTIONS
DEADLOCK

A system is in a deadlock state if there exists a set of

transactions such that every transaction in the set is
waiting for another transaction in the set.

Dealing with Deadlock problem

1. Deadlock prevention
2. Deadlock detection and recovery
Deadlock prevention
Deadlock prevention protocol to ensure that the system
will never enter a deadlock state
1. wait-die
• Non-preemptive technique
• Ti requests a data item currently held by Tj

• Ti is allowed to wait only if it has a timestamp

smaller than that of Tj (that is, Ti is older than Tj )

• Otherwise, Ti is rolled back (dies)

Deadlock prevention

2.wound-wait
• Preemptive technique
• Ti requests a data item currently held by Tj
• Ti is allowed to wait only if it has a timestamp larger
than that of Tj (that is, Ti is younger than Tj )

• Otherwise, Tj is rolled back (Tj is wounded by Ti )

The major problem with both of these schemes is that
unnecessary rollbacks may occur.
Deadlock prevention

Lock timeouts
• another approach for prevention
• a transaction that has requested a lock waits for at
most a specified amount of time.
• Lock not granted, Transaction 🡪 time out
• Transaction rollbacks, restarts
DEADLOCK DETECTION & RECOVERY

DEADLOCK DETECTION
An algorithm that examines the state of the system
is invoked periodically to determine whether a deadlock
has occurred.
RECOVERY
If there is deadlock, then the system must attempt to
recover from the deadlock.
DEADLOCK DETECTION & RECOVERY

Deadlock Detection
• Use wait-for graph
• This graph consists of a pair G = (V, E), where V is a
set of vertices and E is a set of edges. The set of
vertices consists of all the transactions in the system.
• If transaction Ti is waiting for transaction Tj to release a

data item that it needs, the edge is Ti🡪Tj

• If there is a Cycle in graph, then it has a Deadlock
DEADLOCK DETECTION & RECOVERY

Deadlock Detection
wait-for graph
• The edge is removed only when transaction Tj is no

longer holding a data item needed by transaction Ti

• If there is a Cycle in the graph, then it has a Deadlock
DEADLOCK DETECTION

T1 T2
lock-x(Y)
lock-X(X)

W(Y)

W(X)
lock-x(X)
DEADLOCK DETECTION

No Cycle
No Deadlock
DEADLOCK DETECTION

Cycle (T18->T20->T19-T18)
Deadlock
DEADLOCK RECOVERY

1. Selection of a victim
• Select the transaction to rollback
• Select the transaction with minimum cost
Cost
a.How long the transaction has computed, and how
much longer the transaction will compute before it
completes its designated task?
b. How many data items the transaction has used?
DEADLOCK RECOVERY

1. Selection of a victim
Cost
c. How many more data items the transaction needs for
it to complete?
d. How many transactions will be involved in the
rollback?
DEADLOCK RECOVERY

2. Rollback
How far this transaction should be rolled back?
i. Total Rollback
Abort the transaction and then
restart it.
ii. Partial Rollback
Roll back the transaction only as far as
necessary to break the deadlock.
DEADLOCK RECOVERY

3. Starvation
• Must ensure that a transaction can be picked as a
victim only a (small) finite number of times.
• The most common solution is to include the number
of rollbacks in the cost factor.