Department of

CE/IT
DBMS:Database Management
System
Transaction Unit no : 4
Transaction
DBMS (3130703)

Rachit
Adhvaryu
•Transaction concepts
•ACID
Department of

•Transaction Life Cycle

CE/IT

•Serializability
•Recovery
Unit no : 6

•Concurrency Control
Transaction
DBMS (3130703)

•Locking mechanism
•Deadlock
  Anything under execution can be known as
Transaction.
 A transaction is a sequence of operations
performed as a single logical unit of work that
contains one or more than one SQL statements.
1. Read(A); Operations

2. A := A – 50;
3. Write(A); Work as a
4. Read(B);
Transaction single Unit

5. B := B + 50;
6. Write(B);

Transactions
  Atomicity (Either transaction is Complete or No
Transaction)
 Consistency (consistent data must be available
whenever the database is accessed after any
Transaction transaction)
 Isolation (Transactions details of one transaction
must be hidden from other transactions)
(ACID
 Durability (All changes made by the transaction
Properties)
must remain permanent through out the database)
 Atomicity
 This property states that, in a transaction either
all of its operations are executed or none.
 Either transaction execute 0% or 100%.
Transaction  For example, consider a transaction to transfer
(ACID Rs. 1000 from account A to account B.
Properties)  So, if Rs. 1000 is deducted from account A, then
it must be added to account B else in case of
error, it must be added back to Account A.
 Consistency
 Consistent data/values must be available after
any transaction.
 If the database was in a consistent state before
the execution of a transaction; then it must
remain consistent after the execution of the
transaction is completed.
Transaction
(ACID  If the amount has been debited from account A
Properties) and has been added to account B, then both the
accounts must show the amount after the
transaction has been performed.
 For e.g. Initial amount in account A = 5000 and
account B = 3000. Amount to be transferred
from A to B = 1000.
 Thus, after the transaction is completed, amount
 Isolation
 Transactions details of one transaction must be
hidden from other transactions until the
Transaction transaction is committed.
 Intermediate transaction results must be hidden
from other concurrently executed transactions.
(ACID
 For e.g. if account A start transferring amount to
Properties)
account B, then no other transaction should be
allowed to access account A until the current
transaction is fully completed.
 Durability
 All changes made by the transaction must
remain permanent through out the database.
 After a transaction completes successfully, the
changes to the database must be permanent,
even if system fails.
Transaction
(ACID  For e.g. Initial amount in account A = 5000 and
Properties) account B = 3000. Amount to be transferred
from A to B = 1000.
 Thus, after the transaction is completed, amount
in Account A should be 4000 and in account B
should be 4000.
 This change should remain permanent until some
other transaction changes any account’s amount.
 Active
 This is the initial state.
 The transaction remains in this state while execution.

Partial Committed
 It is a state where a transaction actually enter in its last
operation.
Transaction
Failed
(State  An execution cannot be performed due to errors.
Diagram  Once a transaction cannot be completed, any changes that
it made must be undone rolling it back.
or
Committed
Life Cycle)  It is a state where a transaction has completed all its
operations and changes to the database are reflected
 We cannot abort or rollback a committed transaction.

Aborted
 The state after the transaction has been rolled back and
the database has been restored to start of the transaction
state.
  It is a state where a transaction has
completed all its operations and changes to
the database are reflected
 It is a state where a transaction actually
 We cannot abort or rollback a committed
enter in its last operation.
transaction.

Partial
Committ Committe
ed d
Transaction
(State Active End
Diagram
or
Failed Aborted
Life Cycle)
 This is the initial state.
 An executioncannot
 The be performed
The state due to
after the transaction has been
transaction remains in
errors.
this state rolled back and the database has been
while execution.
 Once a transaction cannot
restored be completed,
to start of the transaction state.
any changes that it made must be undone
rolling it back.
 1. Read (X)

 This operation is mainly used for accessing the

data from the database.

 It transfers the data item accessed from the

database to the local buffer/memory.
Transaction
(Operations) 2. Write (X)

 This operation is mainly used for

updating/modifying the data in the database.

 It updates the data of the database as a result of

any transaction been executed.
  A schedule is a process of grouping and
ordering the operation of transactions.

 A schedule is a sequence in which all the

operations are executed.

Transaction  A schedule is required in a database because

(Schedule) when some transactions execute in parallel, they
may affect the result of the transaction.

 If a transaction is updating the data in the

database and other transaction at the same time
is accessing the same data, then the result of the
database is fully dependent on the sequence of
these transactions.
 T1 T2
Read (A)
A = A - 1000
Write (A)
Read (B)
B = B + 1000
Write (B)
Commit
Read (A)
Transaction
(Schedule - T = A * 0.7
A=A-T
Write (A)
Example)
Read (B)
B=B+T
Write (B)
Commit
  A serial schedule is one in which no transaction
starts until an active transaction is complete or
commit.
Transaction
(Serial  Transactions are executed one by one in a
sequence.
Schedule)
 This type of schedule is called a serial schedule,
as transactions are executed in a serial manner.
 T1 T2
Read (A)
A = A - 1000
Write (A)
Read (B)
B = B + 1000
Write (B)
Transaction Commit
(Serial Read (A)
T = A * 0.7
A=A-T
Schedule
Example) Write (A)
Read (B)
B=B+T
Write (B)
Commit
  Schedule that interferes during the execution of
different transactions.

Transaction  It means that any other transaction starts before

(Interleaved the active transaction commits.

Schedule)  Execution can switch between the transactions

in any of the schedules.
 T1 T2
Read (A)
A = A - 1000
Write (A)
Read (B)
B = B + 1000
Write (B)
Transaction
(Interleaved Read (A)
T = A * 0.07
A=A-T
Schedule
Example) Write (A)
Commit
Read (B)
B=B+T
Write (B)
Commit
  Each transaction preserves database consistency

 A schedule is serializable if it is equivalent to a

serial schedule.

 In serial schedules, execution of one transaction

Transaction is allowed at a time i.e. no concurrency is
(Serializability) allowed.

 In serializable schedules, execution of more than

one transactions are allowed at a same time i.e.
concurrency is allowed.

 Types (forms) of serializability

 Conflict serializability
 View serializability
  Let o1 and o2 be the two operations of
transactions T1 and T2 respectively.

 o1 = read(T), o2 = read(T) => o1 and o2 don’t

conflict

 o1 = read(T), o2 = write(T) => o1 and o2

conflict
Transaction
(Conflicting
Operations)  o1 = write(T), o2 = read(T) => o1 and o2
conflict

 o1 = write(T), o2 = write(T) => o1 and o2

conflict

 Operations o1 and o2 conflict if there exists at

least one of these operations o1 or o2 wrote T.
  If a given schedule can be converted into a serial
schedule by swapping its non-conflicting
operations, then it is called as a conflict
serializability
T1 T2 T1 T2
Read (A) Read (A)
A = A - 1000 A = A - 1000
Write (A) Read (A) Write (A) Read (B)
T = A * 0.25 B = B + 50
Transaction A=A-T Write (B)
Write (A)
(Conflict Commit

Serializability)
Read (A)
Read (B)
T = A * 0.25
B = B + 50
Read (B) A=A-T
Write (B) Read (B)
B=B+T Write (A)
Commit B=B+T
Write (B)
Write (B)
Commit
Commit
  Let there be two schedules with the same set of
transactions. Both the schedules are said to be
Transaction view serialized, if the following three conditions
are satisfied, for each data item T:
(View
 Initial Read
Serializability)
 Updated Read

 Final Write
 Initial Read
 If in schedule R1, transaction T1 reads the initial
value of T, then in schedule R2 also transaction
T1 must read the initial value of T.
Schedules R1 and R2
R1
are not view
Transaction T1 : Read (T) equivalent because
(View T2 : Write (T) initial read operation
in R1 is done by T1
Serializability) R2 and in R2 it is done by
T2
T1 : Write (T) Schedules R1 and R3
T2 : Read (T) are view equivalent
because initial read
R3 operation in R1 is
T1 : Read (T) done by T1 and in R3
it is also done by T1
T2 : Read (T)
 Update Read
 If in schedule R1 transaction T1 executes
read(T), and that value was produced by
transaction T2 (if any), then in schedule R2 also
transaction T1 must read the value of T that was
produced by transaction T2.
R1 R2
Transaction T1 T2 T3 T1 T2 T3
(View Write Write
(A) Write Write (A)
Serializability) (A) Read (A) Read
(A) (A)

Schedules R1 and R2 are not view equivalent

because; in R1, T3 reads the data item updated by
T2 and in R2, T3 reads the data item updated by
T1.
 Update Read
 If in schedule R1 transaction T1 executes
read(T), and that value was produced by
transaction T2 (if any), then in schedule R2 also
transaction T1 must read the value of T that was
produced by transaction T2.
R1 R2
Transaction T1 T2 T3 T1 T2 T3
(View Read Read
Write (A) (A)
Serializability) (A) Write Read
Write Read Write (A) (A)
(A) (A) (A)
Schedules R1 and R2 are view equivalent because;
in R1, T3 reads the data item updated by T2 and in
R2, T3 reads the data item updated by T2.
 Final Write
 If in schedule R1, transaction T1 performs final
write operation on some data item T, then in
schedule R2, transaction T1 also performs final
write operation on same data item T.
R1 R2
Transaction T1 T2 T3 T1 T2 T3
(View Write Read
(A) Read Write (A)
Serializability) (A) Write (A) Write
(A) (A)

Schedules R1 and R2 are view equivalent because;

in R1 and R2, final write on data item A; is
performed by transaction T3.
  Two phase commit protocol ensures that all the
participating nodes perform the same task of
transaction.

 It is required to make sure either all the

Transaction databases are updated or none of them are
updated so as to main database synchronization.
(Two Phase
Commit  In two phase commit protocol there is one node
Protocol) which acts as a Coordinator or a Controlling
Node and all other participating nodes are known
as Cohorts or Participant or Slave.

 It involves 2 phases:
 Prepare Phase (Preparing to Commit
transaction)
 Commit/Abort Phase (Final Response)
 Coordinator send
request asking for
ready to commit

Participant send
Reque
reply whether ready st
to commit or not Prepar prepa to
re
ed
e Prepar
Phase
C om m
it/Abo
rt
Commi
t D on e
Phase

Send “ack” to
inform whether Coordinator inform
commit done or not to do commit
 Prepare Phase

 Once each slave completes its transaction, it

sends a “DONE” message to the Coordinator.
Transaction  When the Coordinator receives “DONE”
(Two Phase message from all the slaves, it sends a
“Prepare” (prepare to commit) message to the
slaves.
Commit
Protocol)
 If a slave wants to commit, it sends a “Ready”
message.

 If a slave do not want to commit, it sends a “Not

Ready” message.
 Commit Phase

 When the Coordinator receives “Ready”

message from all the slaves, it sends a “Global
Commit” message to all the slaves
Transaction
(Two Phase  The slaves commit the transaction and send
Commit “Commit Ack” message back to the Coordinator.
Protocol)  Once a Coordinator receives “Commit Ack”
message from all the slaves, then the
transaction is considered to be Committed or
Completed.
 Commit Phase

 When the Coordinator receives “Not Ready”

message from all the slaves, it sends a “Global
Abort” message to all the slaves
Transaction
(Two Phase  The slaves abort the transaction and send
Commit “Abort Ack” message back to the Coordinator.
Protocol)  Once a Coordinator receives “Abort Ack”
message from all the slaves, then the
transaction is considered to be Aborted or Error.
  There are many scenarios where a transaction
could not reach commit or abort state. Some of
them are:
 Disk Failure
 DBMS Crash
 OS Failure
 Power Failure
Transaction
 This may lead to Data Inconsistency or Data
Loss.
(Database
Recovery)
 For e.g., a DBMS crashes after about 20 out of
25 operations were executed successfully. This
may lead to Inconsistent Database state.

 Database Recovery is the process of restoring a

database and its data to the consistent state.
  The log is a sequence of records, which maintain
information about all the activities done by each
operation on the database.
 A log is kept on stable storage (i.e. HDD) and it
contains:
 Start of transaction
 Transaction-id
 Record-id
 Type of operation (insert, update, delete)
Transaction
(Log Based  Old value, new value
Recovery)  Status of transaction that is committed or
aborted.
 For e.g., when transaction T1 starts, it records
<T1 Start> in the log.
 When T1 is about to execute Write Operation,
just before that, it records new log as
<T1,X,D1,D2>, where X is a data item , D1 is the
value of X before transaction and D2 is the new
 Immediate Database Modification
 Changes to the database are executed
immediately as they happen without waiting for
commit command.
 If the transaction is not committed, then the
complete operation needs to be undone and
Transaction transaction is restarted.
 If the transaction is committed, then changes
(Types of Log T1 A=100,
made will be permanent.
B=200
Based Read (A)
A = A - 50 <T1 start>
<T1, A, 100, 50>
Recovery) Write (A)
Read (B)
B = B + 50 A=50,B=200
Write (B) <T1, B, 200, 250>
Commit A=50,B=250

Before the commit is executed, all

the updates are made in the
 Deferred Database Modification
 Changes to the database are executed only after
the commit command is executed.
 If the transaction is not committed, then the
changes wont be reflected in database and only
transaction is restarted.
Transaction  If the transaction is committed, then all the
changes are reflected
A=100,and will be permanent.
T1
(Types of Log
B=200
Based Read (A)
A = A - 50 <T1 start>
<T1, A, 100, 50>
Recovery) Write (A)
Read (B)
B = B + 50
A=50,B=200
Write (B) <T1, B, 200, 250>
Commit A=50,B=250

After the commit is executed, all the

updates are reflected in the
  It may be possible that Log Based Recovery
consumes more time while recovering the data
using Logs. Thus, to reduce the time
consumption, we can use Checkpoints.
 Checkpoint is a point which describes that any
operation of the transaction done before that
Timpoint are executed
TC correctly
TF and stored safely in
e the database.  T1 will be ignored
T as it is committed
Transaction 1 before
T2 checkpoint.
T3
(Checkpoints)  T2 and T3 will
restart again as
T they were active
4 even after
Failu checkpoint, but
Checkpoint
committed before
time re
Working of Checkpoints in case of Failure.
Failure  T4 will be
completely
ignored as it was
  Shadow Paging is an another method of database
recovery and it is very useful in case of serial
transactions.
 The database is fragmented into fixed sized
blocks referred as PAGES. Each pages are stored
in a Page Table.
Transaction  Shadow Paging maintains 2 Page Tables:
 Current Page Table
 Shadow Page Table
(Shadow
Paging)  When the transaction starts, both the tables are
identical.
 During transaction, only Current Page Table
changes, Shadow Page Table never changes.
 All the operations are performed on Current
Page Table.
 When a database page is updated:
 Page Page 1 Page
1 1
Page 2
Page Page  When the transaction
2 Page 3 2 starts, both Current
Page Page 4 Page Page Table and Shadow
3 3 Page Table points to
Page 5
Page Page Same Pages in New
4 4 Pages
Current New Shadow
Page Page
Transaction Page
5 Page Page
5
Table s Table
(Shadow  When the transaction
Page Page 1 Page
Paging) 1 1 updates Page 2 and
Old Page Page 5, then a new copy
Page 2 Page of the Page 2 and 5 is
2 2 created in New Pages.
Page 3
Page Page  Current Page Table
3 Page 4
3 points to New Copy and
Old Page Shadow Page Table
Page 5 Page
4 4 continues pointing Old
New Page Copy
Page 2 Page  Thus, in case of Failure,
Current
5 New Shadow
5
Page Shadow Page Table can
Page Page
New Page
be used to recover the
  Cascading Rollback
 A cascading rollback occurs in database
systems when a transaction (T1) causes a
failure and a rollback must be performed.
 Other transactions dependent on T1's
actions must also be rollbacked due to T1's
failure, thus causing a cascading effect.
That is, one transaction's failure causes
many to fail.
Transaction
If T10 fails, T11 and T12
(Database
Recovery) must also be rolled
back.

 If in a schedule, a transaction is not allowed to read

a data item until the last transaction that has written
it is committed or aborted, then such a schedule is
called as a Cascadeless Schedule.
  Concurrency control is the procedure for
managing simultaneous operations without
conflicting with each other.
 Concurrency control is used to address
conflicts which occur with a multi-user system
who have access to perform READ and WRITE
Concurrency operation in database.
Control  If T1 conflicts with T2 over a data item A, then
the existing concurrency control decides if T1
or T2 should get the A and if the other
transaction is rolled-back or waits.
 Resolve read-write and write-write conflicts.
 Apply isolation through mutual exclusion
between conflicting transactions.
 Concurrency control helps to ensure
  Allowing Concurrent execution of operations
may lead to following problems:
 Lost Update: if two transactions T1 and T2
both read the same data and then update it;
in this case, first update will be overwritten
by the second update.
 Dirty Read: when one transaction update
Concurrency
Control some item and then fails. Moreover, this
updated item is accessed by another
transaction before it is rolled back to its
initial value.
 Incorrect Retrieval: when one transaction
accesses data to use it in other operation;
but before it can use, another transaction
updates that data and commits.
  A lock is a variable associated with data item to
control concurrent access to that data item.
 Data items can be locked in 2 ways:
 Exclusive (X) mode: Data item can be both
read as well as write. X-lock is requested
using lock-X instruction.
Concurrency  Shared (S) mode: Data item can only be
Control read. S-lock is requested using lock-S
instruction.
 Lock-compatibility
T1 ---------------------------- matrix:
T2------


  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.
Concurrency
 If a lock cannot be granted, the requesting
Control
(Lock Based transaction is made to wait till all incompatible
Protocol) locks held T2:by other transactions
 Example have been
of Transactions
released.
lock-S(A); using Locking.
read
(A);  A locking protocol is a
set of rules followed by all
unlock(A); transactions while
lock- requesting and releasing
  The execution phase of transaction can be described
as following:
 When execution of transaction starts, create a
list of data items and type of lock, it needs and
request for that lock.
 When all the locks are granted, transaction
Concurrency continues execution of its operation.
Control  As soon as the transaction releases its first lock,
it cannot demand for any lock; but can only
release the acquired locks.
(Lock Based
Protocol) Transaction
Lock Request Execution Lock Release

Transaction
T begin T end Time
  Consider the following schedule:

Concurrency
Control
(Pitfalls of
 Neither T3 nor T4 can make progress. lock-
X(B) causes T4 to wait for T3 to release its lock
Lock Based
Protocol) on B, while 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 must be released.
  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
Concurrency example:
Control  Transaction may be waiting for an X-lock on
an item, while a sequence of other
transactions request and are granted an S-
(Pitfalls of
Lock Based lock on the same item.
Protocol)  The same transaction is repeatedly rolled back
due to deadlocks.
 Starvation can be managed in following way:
 There is no other transaction holding a lock
that arises a certain type of conflicts.
 There is no other transaction who requested
  The Two Phase Lock protocol has 2 phases:
 Growing Phase:
 transaction may obtain locks
 transaction may not release locks
 Shrinking Phase:
Concurrency  transaction may release locks
Control  transaction may not obtain locks
(Two Phase  It ensures serialized transactions based on lock
points (the point where a transaction acquired
its final lock).
Lock
Protocol)
Growing Phase Shrinking Phase

Transaction
T begin T end Time
  The Two Phase Lock Conversions are as follows:
 Growing Phase:
 transaction receive Lock - S
Concurrency
Control  transaction receive Lock - X
(Two Phase  transaction convert Lock - S to Lock - X
Lock  Shrinking Phase:
 transaction releases Lock - S
Protocol –  transaction releases Lock - X
Lock  transaction convert Lock - X to Lock – S
Conversions) and release
 It ensures serialized transactions.
  The Two Phase Lock can be of 2 types:
 Strict two phase locking protocol:
 A transaction may release all the shared
locks after the Lock Point, but cannot
release any of the exclusive locks until
Concurrency the transaction commits or aborts.
Control  It ensures that if the data is being
(Two Phase modified by one transaction, then other
transaction cannot read it until first
transaction commits.
Lock
Protocol)  Rigorous two phase locking protocol:
 A transaction is not allowed to release
any lock (either shared or exclusive) until
it commits.
 Until the transaction commits, other
transaction can not acquire even a
  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
Concurrency shared locks.
Control  shared and intention-exclusive (SIX): the
subtree rooted by that node is locked
T1 ----------------------------

explicitly in shared mode and explicit locking

(Intention IS IX S S IX X
Locking) is
IS being done by exclusive lock.
Intention
   
T2------

Lock
IX     

Compatibili
ty Matrix
S     

S IX     

X     
  Data Items are represented in a tree like
structure. It has a parent as well as child.
 If a lock is acquired on Parent node, then
automatically, all its children are locked.
 If Page2 has been locked by
any transaction, then all its
Concurrency children i.e. Record1, Record
2, Field1 and Field2 will be
locked.
Control
 If any transaction requests
lock on any child, then
(Multiple
Granularity) compiler checks whether a
Lock on any parent has not
 been given.
At the same time, if other
transaction request lock on
Record2, then lock will not be
granted as its Parent Page 2
has been locked by some other
  Transactions send lock and unlock requests to
Lock Manager. All transactions has to wait for
lock manager’s response.
 Lock manager responds to the request with
either “Lock Granted” or “Wait” message.
 Lock manager keeps all the records of lock
Concurrency grants and pending requests in a Lock Table.
Control  Dark rectangles indicate
granted locks, white ones
(Implementing indicate waiting requests.
Locking)  It has the record of type of
locks issued on the data
items.
 The new requests are listed
in the queue from the
bottom of the table.
Granted

 If a transaction releases a
Waiting

lock, it will check which

transaction can be provided
  Each transaction is issued a timestamp when it
enters the system. An old transaction T1 has
time-stamp TS(T1) and new transaction T2 is
assigned time-stamp TS(T2), then following
condition satisfies: TS(T1) < TS(T2). For e.g.
Concurrency TS(T1) = 0002 and TS(T2) = 0005, then TS(T1)
Control < TS(T2).
 Transaction with older timestamp are give
priority for execution.
(Time Stamp
Based  The protocol manages concurrent execution such
Protocol) that the read and write operations are executed
in timestamp order.
 The protocol maintains for each data Q two
timestamp values:
 W-timestamp(Q): largest time-stamp of any
transaction that executed write(Q)
  Suppose a transaction T1 issues a read(Q).
 If TS(T1) <= W-timestamp(Q), then the read
operation is rejected as write operation is in
execution. For e.g. TS(T1) = 0002, W-
timestamp(Q) = 0008
Concurrency  If TS(T1) >= W-timestamp(Q), then the read
operation is executed as it is assumed that
write operation is committed. For e.g. TS(T1)
Control
(Time Stamp = 0005, W-timestamp(Q) = 0003
Based  Suppose a transaction T1 issues a write(Q).
Protocol)  If TS(T1) <= R-timestamp(Q), then the write
operation is rejected as read operation is in
execution. For e.g. TS(T1) = 0002, R-
timestamp(Q) = 0008
 If TS(T1) >= R-timestamp(Q), then the write
operation is executed as it is assumed that
read operation is complete. For e.g. TS(T1) =
  A deadlock is a situation in which one
transaction is waiting for other transaction to
release the resources.
 Let there be a set of transaction {T1, T2, T3}
such that T1 is waiting for a data item that T2
holds, and T2 is waiting for a data item that T3
holds, T3 is waiting for a data item that T1 holds.
Deadlock
 Here, each transaction is waiting for some other.
Hence, no transaction will work smoothly.
 The only solution to this situation is transaction
being rolled back to its initial state every time
and come again to check the availability of
resources.
  A Deadlock Condition arise only if all these four
conditions are true together.

 Mutual Exclusion: One Process to work at one

time. If any other process requests the same
resource, it will wait till the first release it.

 Hold and Wait: One process holds one

resource and waiting for other resource that
Deadlock
Detection is held by other process.

 Non-Preemption: Process can release

resources only when it has completed its task.
No force to acquire resource

 Circular Wait: One Process waiting for other,

Other waiting for another and thus creates
the cycle.
  The most simpler way to detect deadlock is to
use Wait-for Graph.
 Each Transaction is represented by a node.
When a Transaction Ti is waiting for the resource
held by Tj, a directed edge is drawn from Ti to Tj
(Ti ----- Tj).
 If the Wait-for graph has any cycle, then we can
say there is a Deadlock and all the transactions
in theB cycle are also said to be
B deadlocked.
Deadlock D
Detection D

 A is waiting for
DEADLOC
A K

B and C
C
A C

 A is waiting for B and  B is waiting for D

C  D is waiting for C
 C is waiting for B  C is waiting for B
 B is waiting for D  There is a cycle B – D – C -
 Still, there is no cycle, B, It is a Deadlock. for B, C,
  The most simpler way to recover from deadlock
is to Roll Back any of the transactions.
 The transaction which incurs minimum loss is
rolled back and it is known as Victim.
 The decision to roll back a transaction is made
on following criteria:
Deadlock
Recovery  The transaction which have minimum locks
 The transaction which has executed less work
 The transaction which is very far from
completion
  A Deadlock can be prevented using:

 Wait-Die Approach:
 If an older transaction is requesting a
resource which is held by younger
transaction, then older transaction waits.
 If an younger transaction is requesting a
Deadlock resource which is held by older
Prevention transaction, then younger transaction is
killed and rolled back.
Wait-Die
O needs a resource held O Waits
by Y
Y needs a resource held Y Dies
by O
  A Deadlock can be prevented using:

 Wound-Wait Approach:
 If an older transaction is requesting a
resource which is held by younger
transaction, then older transaction forces
younger transaction to kill the transaction
Deadlock and releases the resource.
Prevention  If an younger transaction is requesting a
resource which is held by older
transaction, then younger transaction waits
till older transaction releases resource.
Wound-Wait
O needs a resource held Y Hurts /
by Y Dies
Y needs a resource held Y Waits
  A Deadlock can be prevented using:

 Timeout-Based Approach:
 A transaction waits for a lock only for a
specified amount of time. After that, the
transaction is rolled back.
 So deadlock never occurs.
Deadlock
Prevention
Thanks