Lec 37-40 PDF

Transaction
Management
Professor Navneet Goyal

Department of Computer Science & Information Systems
BITS, Pilani
Topics
n Overview
n ACID Properties of Transaction
n Concurrency Control
• Motivation
• Problems
• Solutions
• Locking
• Time-stamping
• Validation
n Crash recovery
• Log-based
• Shadow-paging
© Prof. Navneet Goyal, BITS, Pilani
Overview
n A Tx. Is defined as any one execution of a
user program
n Logical unit of DB processing, that includes
one or more DB operations (insert, delete,
update, or retrieval)
n These DB ops. Can be embedded within an
appl. program or can be specified via a high
level language like SQL
n A single appl. program may contain more
than one tx.
n A DB is a collection of named DI ( field,
record, relation)
Overview
n Basic Operations on a DB
n Read
n Write
n read_item(X): Reads a database item
named X into a program variable. To
simplify our notation, we assume that the
program variable is also named X.
n write_item(X): Writes the value of program
variable X into the database item named X.

Overview
n Steps in read (X)
n Find address of block containing X (input(X))
n Copy the disk block into a buffer in memory
n Copy item X from buffer to program variable named X
n Steps in write (X)
n Find address of block containing X
n Copy the disk block into a buffer in memory
n Copy item X from program variable to its current
location in buffer
n Output the buffer block to disk (output(X))
n Read & write are issued by txs.
n Input & output are issued by buffer manager

ACID Properties
A transaction is a unit of program
execution that accesses and possibly
updates various data items.To preserve
the integrity of data the database
system must ensure:
n Atomocity
n Consistency
n Isolation
n Durability
ACID Properties
n Atomicity. Either all operations of the transaction are
properly reflected in the database or none are.
n Consistency. Execution of a transaction in isolation
preserves the consistency of the database.
n Isolation. Although multiple transactions may execute
concurrently, each transaction must be unaware of other
concurrently executing transactions. Intermediate
transaction results must be hidden from other
concurrently executed transactions.
n That is, for every pair of transactions Ti and Tj, it appears to
Ti that either Tj, finished execution before Ti started, or Tj
started execution after Ti finished.
n Durability. After a transaction completes successfully,
the changes it has made to the database persist, even if
there are system failures.

Example
n Transaction to transfer $50 from account A to
account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
n Atomicity requirement — if the transaction fails
after step 3 and before step 6, the system should
ensure that its updates are not reflected in the
database, else an inconsistency will result.
n Consistency requirement – the sum of A and B is
unchanged by the execution of the transaction.

Example (Cont.)
n Isolation requirement — if between steps 3 and 6, another
transaction is allowed to access the partially updated
database, it will see an inconsistent database (the sum A
+ B will be less than it should be).
n Isolation can be ensured trivially by running transactions
serially, that is one after the other.
n However, executing multiple transactions concurrently has
significant benefits, as we will see later.
n Durability requirement — once the user has been notified
that the transaction has completed (i.e., the transfer of
the $50 has taken place), the updates to the database by
the transaction must persist despite failures.

Transaction States
n Active – the initial state; the transaction stays in
this state while it is executing
n Partially committed – after the final statement has
been executed.
n Failed -- after the discovery that normal execution
can no longer proceed.
n Aborted – after the transaction has been rolled
back and the database restored to its state prior to
the start of the transaction. Two options after it
has been aborted:
n restart the transaction; can be done only if no
internal logical error
n kill the transaction
n Committed – after successful completion.

Transaction States

Concurrency
n Concurrent execution of user programs is essential
for good DBMS performance.
n Because disk accesses are frequent, and relatively
slow, it is important to keep the cpu humming by
working on several user programs concurrently.
n A user’s program may carry out many operations on
the data retrieved from the database, but the DBMS
is only concerned about what data is read/written
from/to the database.
n A transaction is the DBMS’s abstract view of a user
program: a sequence of reads and writes.

Concurrency
n Ensuring concurrency, inspite of concurrent
execution requires extra work
n Far easier to insist that txs. Run serially
n 2 good reasons to allow concurrency
n Efficient utilization of system resources
(parallelism of CPU & I/O subsystems)
n Reducing response time of queries and increased
system throughput
n Motivation for using concurrent execution in
a DBMS is essentially the same as the
motivation for using multi-programming in
an OS
Concurrency
n Interleaved Execution
n Different from parallel execution

Concurrency Problems
n Lost Update Problem
n Uncommitted Dependency Problem
n Inconsistent Analysis Problem
n Proposed Solutions:
n Locking (pessimistic)
n Time-stamping (optimistic)
n Validation (optimistic)
n Deadlocks
n Starvation
n Cascading Rollbacks
Lost Update Problem
Time T1 T2 bal(X)
t1 Begin Tx 100
t2 Begin Tx R(balX) 100
t3 R(balX) balx=balx+100 100
t4 balx=balx-10 W(balx) 200
t5 W(balx) Commit 90
t6 Commit 90
Update of T2 was lost!!!

Lost Update Problem
Time T1 T2 bal(X)
t1 Begin Tx 100
t2 Begin Tx R(balX) 100
t3 R(balX) balx=balx+100 100
t4 balx=balx-10 W(balx) 200
t5 W(balx) Commit 90
t6 Commit 90
Could have been avoided if we prevent T1 from reading

till T2’s update has been completed
Uncommitted
Dependency Problem
Time T3 T4 bal(X)
t1 Begin Tx 100
t2 R(balX) 100
t3 balx=balx+100 100
t4 Begin Tx W(balx) 200
t5 R(balX) 200
t6 balx=balx-10 Rollback 200
t7 W(balx) 190
t8 Commit 190
Could have been avoided if we prevent T3 from reading until

after the decision to commit or rollback T4 has been made
Inconsistent Analysis
Problem
Time T5 T6 Bal(x) Bal(z) Sum
t1 Begin Tx 100 25 0
t2 Begin Tx Sum=0 100 25 0
t3 R(balX) 100 25 0
t4 balx=balx-10 R(balX) 100 25 0
t5 W(balx) Sum+=balx 90 25 100
t6 R(balZ) 90 25 100
t7 balz=balz+10 90 25 100
t8 W(balz) 90 35 100
t9 Commit R(balz) 90 35 100
t10 Sum+=balz 90 35 135
t11 W(sum) 90 35 135
t12 commit 90 35 135
Some Terms
n Schedules
n Serial Schedules
n Interleaved Schedules
n Serializable Schedules
n Conflict Serializable
n View Serializable
n Serializability

Serializability
n Schedule
Given a set of txs., any execution of
those txs. (interleaved or otherwise)
is called a schedule
n Every serial schedule preserves
consistency
n Are there any other class of
schedules that are guaranteed to
preserve consistency?
n Yes: Serializable Schedules
Serializability
n A schedule is said to be
serializable if its effect on the DB
state is the same as that of some
serial schedule (regardless of
the initial state of the DB)
n Two schedules are said to be eq.
if they produce the same result
(independent of the initial state of the DB)

Serializability
n Basic Assumption – Each transaction
preserves database consistency.
n Thus serial execution of a set of
transactions preserves database
consistency.
n A (possibly concurrent) schedule is
serializable if it is equivalent to a serial
schedule. Different forms of schedule
equivalence give rise to the notions of:
1.Conflict serializability
2.View serializability

Serializability
n Criterion for correctness of concurrency
n In other words, criterion for correctness of
interleaved schedules
n A schedule is correct, ie, serializable, if it
is EQ. to some serial schedule
n T1 then T2; result x
n T2 then T1; result y
n Both are considered correct!

Serializability
n We ignore operations other than read and
write instructions, and we assume that
transactions may perform arbitrary
computations on data in local buffers in
between reads and writes. Our simplified
schedules consist of only read and write
instructions.

Conflicting Instructions
n Two consecutive actions of different txs.
Are said to be in conflict in an
interleaved schedule if:
n They involve the same DI
n Atleast one of them is a write
n Conflicting actions cannot be swapped
n Non-conflicting actions can be swapped
n Do you agree?
n Because swapping them does not change
the state of the DB

Conflicting Instructions
n Instructions li and lj of transactions Ti and Tj
respectively, conflict if and only if there exists some
item Q accessed by both li and lj, and at least one of
these instructions wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
n Intuitively, a conflict between li and lj forces a (logical)
temporal order between them.
n If li and lj are consecutive in a schedule and they do not
conflict, their results would remain the same even if they
had been interchanged in the schedule.

Conflict Serializability
n If a schedule S can be transformed
into a schedule S´ by a series of
swaps of non-conflicting
instructions, we say that S and S´
are conflict equivalent.
n We say that a schedule S is conflict
serializable if it is conflict
equivalent to a serial schedule

n Take any schedule and make as many
NC swaps as we wish, with the goal of
turning the schedule into a serial
schedule
n If we can do so, then the original
schedule is serializable
n Conflict Serializability is a sufficient
condition for serializability
n Conflict Serializability => Serializability
n Note that CS is not a necessary
condition for S! WHY?
n Schedule 1 can be transformed into Schedule 2, a serial
schedule where T2 follows T1, by series of swaps of non-
conflicting instructions.
n Therefore Schedule 1 is conflict serializable.
Schedule 1 © Prof. Navneet Goyal, BITS, Pilani Schedule 1

Example of a schedule that is not conflict
serializable:
n We are unable to swap instructions in the above

schedule to obtain either the serial schedule <
T3, T4 >, or the serial schedule < T4, T3 >.

Precedence Graph Test
for Conflict Serializability
n Consider a schedule involving T1 & T2
n T1 takes precedence over T2 if there are
actions A1 of T1 & A2 of T2, such that:
n A1 is ahead of A2 in S
n Both involve same DI
n Atleast one of them is a write
n These are exactly the conditions under
which we cannot swap them
n A1 will appear before A2 in any schedule
that is Conflict Eq. to S
n So, if one of these schedules is a serial
schedule, then it must have T1 before T2
n T1: r1(x); r1(z); w1(x)
n T2: r2(z); r2(y); w2(z); w2(y)
n T3: r3(x); r3(y); w3(y)
n S1: r1(x); r2(z); r1(z); r3(x); r3(y);
w1(x); w3(y); r2(y); w2(z); w2(y)
n S2: r1(x); r2(z); r3(x); r1(z); r2(y); r3(y);
w1(x); w2(z); w3(y); w2(y)
Draw the precedence graphs for S1 and S2 and state
whether each schedule is serializable or not.
If a schedule is serializable, write down the equivalent
serial

S1: serializable (T3, T1, T2) – 2.5 S2: Not serializable – 2.5

n CS is not a Necessary Condition for
serializability
n S => CS
n S1: w1(y); w1(x); w2(y); w2(x); w3(x)
n S2: w1(y); w2(y); w2(x); w1(x);w3(x)
Show that S2 is serializable but not CS

n Schedulers in commercial systems
generally use the stronger condition of
conflict serializability
n Why the precedence-graph test works?
n If cycle exists – not conflict serializable
n If no cycle – conflict serializable
• Use mathematical induction!!
T1
TN T2
T7 T3
T6 T4
T5

S
CS
S2
S => CS
S1: w1(y); w1(x); w2(y); w2(x); w3(x)
S2: w1(y); w2(y); w2(x); w1(x);w3(x)
S1 is serial & S2 produces the same result as
S1, but S2 is not CS.
n Commercial systems check only for CS
n Any system using CS would have blocked S2
n Should S2 have been blocked?
n System should have checked that S2
produces the same outcome as serial
schedule S1 and should have allowed S2
n Computationally expensive to do so
n We need a less ‘stringent’ condition than CS!
n A condition that would allow some more
serialzable schedules than CS
n Ideally we should allow all serializabe
schedules
n Are we asking for too much?
View Serializability
S
Blind
writes
CS VS

What is
View Serializability?
n Less stringent than conflict serializability
n Like CS, based on read and write operations of a
transaction.
n Let S and S´ be two schedules with the same set
of transactions T1,T2,…Tn are ‘view equivalent’ if
the following three conditions are met:
1. For each data item x, if Ti reads the initial values of x
in S it must do the same in S’
2. For each DI x, if Ti reads x in S, and the value was
produced by Tj, the Ti must read the value if x that
was produced by the same write op. of Tj in S’’ also
3. Same transaction should finally write x in both S & S’
1 & 2 ensure that each tx. reads the same value in both
schedules and, therefore, performs the same
computation.
Condition 3, coupled with 1 & 2, ensures that both the
schedules result in the same final system state
View Serializability
n A schedule S is view serializable it is view equivalent
to a serial schedule.
n Every conflict serializable schedule is also view
serializable.
n Below is a schedule which is view-serializable but not
conflict serializable.
Blind
writes
n What serial schedule is above equivalent to? T3,T4,T6

n T3 reads Q in both schedules & T6 writes the final values
of Q in both schedules T3T4T6 and T3,T4,T6
n Every view serializable schedule that is not conflict
serializable has blind writes. (T4 & T6 perform write
(Q) without performing read(Q))
Test for View
Serializability
n The precedence graph test for conflict
serializability cannot be used directly to test for
view serializability.
n Extension to test for view serializability has cost
exponential in the size of the precedence graph.
n The problem of checking if a schedule is view
serializable falls in the class of NP-complete
problems.
n Thus existence of an efficient algorithm is extremely
unlikely (Ullman 1988)*
* Ulmann, J.D. (1988). Principles of Databases & Knowledge base

systems, Vol. 1, Rockville MD, Computer Science Press.

Test for View
Serializability
n Practical algorithms that just check some
sufficient conditions for view serializability
n There may be VS schedules that do not satisfy
the sufficient conditions!

Test for View
Serializability
n FIND OUT HOW YOU WOULD TEST
A GIVEN SCHEDULE FOR VIEW
SERIALIZABILITY!!!

Polygraphs
n Generalization of precedence graph
n Hypothetical txs. T0 & Tf
n T0 wrote initial values of each DI read by any
tx. in s1 or s2
n Tf reads every DI written by one or more txs.
after each schedule ends
n For every ri(A) in one of the schedules, we can
find wj(A) that most closely preceded ri(A)
n Tj is the ‘source’ of ri(A)
n Tj could be T0 and Ti could be Tf

Polygraphs
n Node for eaxh tx. plus that for T0 & Tf
n For each ri(X), with source Tj, place arc
TjèTi
n Suppose Tj is source of ri(X), & Tk is
another writer of X. Tk is not allowed to
intervene between Tj & Ti, so it must
appear before Tj or after Ti. Arc Pairs
n Arc pairs to single arc
n Tj is T0, only single arc TièTk
n Ti is Tf, only single arc TkèTj
Polygraphs
n Consider the schedule:
r2(B), w2(A), r1(A), r3(A), w1(B), w2(B), w3(B)

Lock-Based Protocols
n A lock is a mechanism to control concurrent access
to a data item
n 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.
n Lock requests are made to concurrency-control
manager. Transaction can proceed only after request
is granted.
n Lock-compatibility matrix
n 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
n Any number of transactions can hold shared locks
on an item,
n but if any transaction holds an exclusive on the item no
other transaction may hold any lock on the item.
n 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.
n Why 2PL works?
n Use mathematical induction!!

Pitfalls of Lock-Based
Protocols
n Consider the partial schedule
n 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.
n Such a situation is called a deadlock.
n To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.
Pitfalls of Lock-Based
Protocols
n The potential for deadlock exists in most
locking protocols.
n Deadlocks are a necessary evil.
n Starvation is also possible if concurrency
control manager is badly designed. For
example:
n 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.
n The same transaction is repeatedly rolled back due
to deadlocks.
n Concurrency control manager can be
designed to prevent starvation.
The Two-Phase Locking
Protocol
n This is a protocol which ensures conflict-serializable
schedules.
n Phase 1: Growing Phase
n transaction may obtain locks
n transaction may not release locks
n Phase 2: Shrinking Phase
n transaction may release locks
n transaction may not obtain locks
n 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).

2PL
n 2PL does not ensure freedom from deadlocks
n 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
n Rigorous two-phase locking is even
stricter: here all locks are held till
commit/abort. In this protocol transactions
can be serialized in the order in which they
commit.
2PL
n There can be conflict serializable schedules that
cannot be obtained if two-phase locking is used.
n However, in the absence of extra information
(e.g., ordering of access to data), two-phase
locking is needed for conflict serializability in the
following sense:
Given a transaction Ti that does not follow two-
phase locking, we can find a transaction Tj that
uses two-phase locking, and a schedule for Ti
and Tj that is not conflict serializable.

Implementation of
Locking
n A lock manager can be implemented as a separate
process to which transactions send lock and unlock
requests
n 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)
n The requesting transaction waits until its request is
answered
n The lock manager maintains a data-structure called a
lock table to record granted locks and pending
requests
n The lock table is usually implemented as an in-memory
hash table indexed on the name of the data item being
locked
n Black rectangles indicate
Lock Table granted locks, white ones

indicate waiting requests
n Lock table also records the
type of lock granted or
requested
n 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
n Unlock requests result in the
request being deleted, and
later requests are checked to
see if they can now be granted
n If transaction aborts, all
waiting or granted requests of
the transaction are deleted
n lock manager may keep a list of
locks held by each transaction,
to implement this efficiently

Implementation of
Locking
n Algorithm guarantees freedom
from starvation for lock requests,
since a request can never be
granted while a request received
earlier is waiting to be granted

Recoverability
n We now know what schedules are
acceptable from the viewpoint of
consistency of the DB, assuming implicitly
that there are no tx. failures
n If a tx. Ti fails, for whatever reason, we
need to undo the effect of this tx. to ensure
atomicity
n If concurrency is allowed, it is also
necessary that any tx. Tj that is dependent
on Ti (ie, read a DI written by Ti) is also
aborted
n To achieve this surety, we need to place
restrictions on the type of schedules
permitted
Recoverable Schedules
Need to address the effect of transaction failures on concurrently
running transactions.
n Recoverable schedule — if a transaction Tj reads a data item
previously written by a transaction Ti , then the commit
operation of Ti appears before the commit operation of Tj.
n The following schedule is not recoverable if T9 commits
immediately after the read
n Non-recoverable schedule
n If T8 should abort, T9 would have read (and possibly shown to

the user) an inconsistent database state. Hence, database
must ensure that schedules are recoverable.
Recoverable Schedules
n A Recoverable Schedule is one
where, for each pair of txs. Ti & Tj ,
such that Tj reads a DI previously
written by Ti, the commit operation
of Ti appears before the commit of Tj

Cascading Rollbacks
n Cascading rollback – a single transaction failure leads to a
series of transaction rollbacks. Consider the following
schedule where none of the transactions has yet committed
(so the schedule is recoverable)
if T10 fails,
T11 and T12 must also be rolled back.
n Can lead to the undoing of a significant amount of work

Cascadeless Schedules
n Cascadeless schedules — cascading
rollbacks cannot occur; 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.
n Every cascadeless schedule is also recoverable
n It is desirable to restrict the schedules to those
that are cascadeless

Concurrency Using
Timestamping
n Optimistic approach in the sense
that it assumes that no
unserializable behavior will occur
n Only fix things when a violation is
apparent
n In contrast, locking protocols
assume that things will go wrong
and prevent txs. from engaging in
unserializable behavior

Timestamp-Based
Protocols
n Scheduler needs to assign each tx. A
unique no., its timestamp
n Two simple methods of implementing it:
n System Clock - tx’s timestamp is equal to the
value of the clock when the tx. enters the system
n Logical Counter – incremented after a new TS has
been assigned. Tx’s TS is equal to the value of
the counter

Timestamp-Based
Protocols
n Each transaction is issued a timestamp when it enters the
system. If an old transaction Ti has time-stamp TS(Ti), a
new transaction Tj is assigned time-stamp TS(Tj) such that
TS(Ti) <TS(Tj).
n The protocol manages concurrent execution such that the
time-stamps determine the serializability order.
n In order to assure such behavior, the protocol maintains for
each data Q, two timestamp values:
n W-timestamp(Q) is the largest time-stamp of any transaction
that executed write(Q) successfully.
n R-timestamp(Q) is the largest time-stamp of any transaction
that executed read(Q) successfully.

Timestamp-Based
Protocols
n The TS ordering protocol ensures that any
conflicting read and write operations are
executed in TS order.
n Suppose a transaction Ti issues a read(Q)
1. If TS(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. If TS(Ti)≥ W-timestamp(Q), then the read
operation is executed, and R-timestamp(Q) is set
to the maximum of R-timestamp(Q) and TS(Ti).

Timestamp-Based
Protocols
n Suppose that transaction Ti issues write(Q).
1. If TS(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. If TS(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, and
W-timestamp(Q) is set to TS(Ti).

Example
A partial schedule for several data items for
transactions with timestamps 1, 2, 3, 4, 5
T1 T2 T3 T4 T5
read(X)
read(Y)
read(Y)
write(Y)
write(Z)
read(Z)
read(X)
abort
read(X)
write(Z)
abort
write(Y)
write(Z)
Correctness of Timestamp-
Ordering Protocol
n The timestamp-ordering protocol guarantees
conflict serializability since all the arcs in the
precedence graph are of the form:
transaction transaction
with smaller with larger
timestamp timestamp
Thus, there will be no cycles in the precedence

graph
n Conflicting actions are performed in TS order
n Timestamp protocol ensures freedom from
deadlock as no transaction ever waits.
n But the schedule may not be cascade-free, and
may not even be © recoverable.
Prof. Navneet Goyal, BITS, Pilani
Example: TSOP
T14 T15
read(B)
read(B)
B:= B-50
write (B)
read(A)
read(A)
display (A+B)
A:= A+50
write (A)
display (A+B)

2PL vs. TSOP
n There exists schedules that are possible under
2PL, but are not possible under TSOP, and vice-
versa
n TSOP allows some serializable schedules that
2PL does not (although converse is also true).
S
2PL TS
CS VS

Deadlock Handling
System is deadlocked if there is a set
of transactions such that every
transaction in the set is waiting for
another transaction in the set.
n Deadlock prevention protocols ensure that the
system will never enter into a deadlock state.
n Deadlock detection & recovery: protocols
allow system to enter into a deadlock, detect
them as quickly as possible & recover from it by
rolling back one or more txs.

Deadlock Prevention
Strategies
Following schemes use transaction
timestamps for the sake of deadlock
prevention alone.
n wait-die scheme — non-preemptive
n older transaction may wait for younger one to release
data item. Younger transactions never wait for older
ones; they are rolled back instead.
n a transaction may die several times before acquiring
needed data item
n wound-wait scheme — preemptive
n older transaction wounds (forces rollback) of younger
transaction instead of waiting for it. Younger
transactions may wait for older ones.
n may be fewer rollbacks than wait-die scheme.

Deadlock Prevention
Strategies
Both in wait-die and in wound-wait
schemes, a rolled back
transactions is restarted with its
original timestamp. Older txs. thus
have precedence over newer ones,
and starvation is hence avoided.

Example: WD & WW
There are four transactions T1, T2, T3 and T4 with
TS(T1)<TS(T2)<TS(T3)<TS(T4).
T2 is waiting for T1, T3 waiting for T2, T4 waiting for T1.
n How many transactions would be rolled back in wait-die
scheme
n How many transactions would be rolled back in wound-wait
scheme
n Which transaction would get executed first in the wait-die
scheme
n Which transaction would get executed first in the wound-wait
scheme
n Which scheme is better in the above scenario?

Problem: WD & WW
There are four transactions T1, T2, T3 and T4 with
TS(T1)<TS(T2)<TS(T3)<TS(T4).
T1 is waiting for T2, T2 waiting for T3, T1 waiting for T4.
n How many transactions would be rolled back in wait-die
scheme
n How many transactions would be rolled back in wound-wait
scheme
n Which transaction would get executed first in the wait-die
scheme
n Which transaction would get executed first in the wound-wait
scheme
n Which scheme is better in the above scenario?

Deadlock Detection &
Recovery
n Wait-for-Graphs (WFG)
Wait-for graph without a cycle Wait-for graph with a cycle

Problem: WFG
Data items locked Data items
Transaction by transaction transaction is
waiting for
T1 X2 X1, X3
T2 X3, X10 X7, X8
T3 X8 X4, X5
T4 X7 X1
T5 X1, X5 X3
T6 X4, X9 X6
T7 X6 X5
• Identify all deadlocks

• How do you propose to break the deadlocks?
• Identify all deadlock victims
Assumption: All transactions are holding incompatible locks.

Deadlock Recovery
n When deadlock is detected :
n Some transaction will have to rolled back (made a
victim) to break deadlock. Select that transaction
as victim that will incur minimum cost.
n Rollback -- determine how far to roll back
transaction
• Total rollback: Abort the transaction and then
restart it.
• More effective to roll back transaction only as far as
necessary to break deadlock.
n Starvation happens if same transaction is always
chosen as victim. Include the number of rollbacks
in the cost factor to avoid starvation

Deadlock Victim
n Choose a deadlock victim based on
the following parameters:
n How much work the tx. has done?
n How far is it from completion?
n How many resources (DIs) it is holding?
n How many txs. will be involved in the
rollback
n How many times it has been rolled back?
n How many deadlocks it is involved in?

Multiple Granularity
n Allow data items to be of various sizes and define a
hierarchy of data granularities, where the small
granularities are nested within larger ones
n Can be represented graphically as a tree
n When a transaction locks a node in the tree explicitly, it
implicitly locks all the node's descendents in the same
mode.
n Granularity of locking (level in tree where locking is done):
n fine granularity (lower in tree): high concurrency, high
locking overhead
n coarse granularity (higher in tree): low locking overhead,
low concurrency
Example of Granularity
Hierarchy
The levels, starting from the coarsest (top) level are

n database
n area
n file
n record
Intention Lock Modes
n In addition to S and X lock modes, there are
three additional lock modes with multiple
granularity:
n intention-shared (IS): indicates explicit locking at a
lower level of the tree but only with shared locks.
n intention-exclusive (IX): indicates explicit locking at
a lower level with exclusive or shared locks
n 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.
n intention locks allow a higher level node to be
locked in S or X mode without having to check
all descendent nodes.
Compatibility Matrix with
Intention Lock Modes
n The compatibility matrix for all lock
modes is:
IS IX S S IX X
IS ü ü ü ü ×
IX ü ü × × ×
S ü × ü × ×
S IX ü × × × ×
X × × × × ×
Q&A
Thank You

Lec 37-40 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Lec 37-40 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Transaction

Professor Navneet Goyal

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

t2 Begin Tx R(balX) 100

t3 R(balX) balx=balx+100 100

t4 balx=balx-10 W(balx) 200

Update of T2 was lost!!!

t2 Begin Tx R(balX) 100

t3 R(balX) balx=balx+100 100

t4 balx=balx-10 W(balx) 200

Could have been avoided if we prevent T1 from reading

Could have been avoided if we prevent T3 from reading until

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

Schedule 1 © Prof. Navneet Goyal, BITS, Pilani Schedule 1

n We are unable to swap instructions in the above

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

Show that S2 is serializable but not CS

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

n What serial schedule is above equivalent to? T3,T4,T6

* Ulmann, J.D. (1988). Principles of Databases & Knowledge base

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

n A transaction may be granted a lock on an item if

© Prof. Navneet Goyal, BITS, Pilani

n Neither T3 nor T4 can make progress — executing lock-

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

Lock Table granted locks, white ones

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

n If T8 should abort, T9 would have read (and possibly shown to

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani

Thus, there will be no cycles in the precedence

© Prof. Navneet Goyal, BITS, Pilani

© Prof. Navneet Goyal, BITS, Pilani