Unit-4

Transaction Management and

Concurrency control

Transaction Management Syllabus- ACID

properties, Transaction States, concurrency control,
Schedule- Serial and concurrent, Serializability- Conflict
Serializability, View Serializability, Recoverable Schedules,
Cascade less schedules
Transaction

The term transaction refers to a collection

of operations that form a single logical unit
of work.
A transaction is an atomic unit.
For instance, transfer of money from one
account to another is a transaction
consisting of two updates, one to each
account.
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)
 PROPERTIES OF TRANSACTION
 Atomicity: either transaction is completed or completely
aborted.
 It is important that either all actions of a transaction
be executed completely, or, in case of some failure,
partial effects of each incomplete transaction be
undone.
 This “all-or-none” property is referred to as atomicity.
 Consistency: if system is in consistent state before
transaction, then it should be in consistent state after
transaction.
PROPERTIES OF TRANSACTION

 Isolation: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.
 Thus, database systems must provide mechanisms to
isolate transactions from the effects of other concurrently
executing transactions.
After a transaction completes
 Durability:

successfully, the changes it has made to the

database persist, even if there are system failures.
STATES OF TRANSACTION
STATES OF TRANSACTION

 Active, the initial state; the transaction stays in this state while it is
executing.
 Partially committed, after the final statement has been executed.
 At this point, the transaction has completed its execution,
but it is still possible that it may have to be aborted, since
the actual output may still be temporarily residing in
main memory, and thus a hardware failure may preclude
its successful completion.
 Failed, after the discovery that normal execution can no longer proceed.
 Aborted, after the transaction has been rolled back and the database
has been restored to its state prior to the start of the transaction.
 • Committed, after successful completion.
A Simple Transaction Model

Transactions access data using two operations:

 read(X), which transfers the data item X from the
database to a variable, also called X, in a buffer in
main memory belonging to the transaction that
executed the read operation.
 write(X), which transfers the value in the variable X
in the main-memory buffer of the transaction that
executed the write to the data item X in the
database.
 LOG BASED RECOVERY
Various types of log records:
< Ti , Start > : Transaction Ti has started.
< Ti , Commit > : Transaction Ti has committed.
< Ti , Abort > : Transaction Ti has aborted.
< Ti , X , V1 , V2 > : Transaction Ti has performed Write
operation.
Where: Ti is unique identifier of transaction
X is unique identifier of data written.
V1 is old value of X before Write.
V2 is New Value of X after Write.
Transaction Log Records Values

  < Ti , Start >  

Ti: Read ( A )   Read A = 1000

A: = A – 50    

Write ( A ) < Ti , A , 1000 , 950 >  

Read ( B )   Read B = 2000

B: = B + 50    

Write ( B ) < Ti , B , 2000 , 2050  

>
  < Ti , Commit >  
 Types of log based Recovery
1. Deferred database modification Technique
 Defers execution of all write operations till Partial
completion of Transaction.
 The recovery scheme used: Redo ( Ti )
2. Immediate Update Technique
 The recovery scheme used:
 Undo ( Ti )
 Redo ( Ti )
 CONCURRENCY CONTROL

 when multiple transactions executes

simultaneously, system has to control interaction
between transactions so that Database does not
enter in inconsistent state.

 A collection of methods used to implement this

control is called as concurrency control.
Reasons for allowing concurrency

1. Improved throughput and resource utilization.

 A transaction consists of many steps. Some involve I/O activity;
others involve CPU activity. The CPU and the disks in a computer
system can operate in parallel.
 Therefore, I/O activity can be done in parallel with processing at
the CPU. The parallelism of the CPU and the I/O system can
therefore be exploited to run multiple transactions in parallel.
 All of this increases the throughput of the system—that is, the
number of transactions executed in a given amount of time.
 Correspondingly, the processor and disk utilization also increase;
in other words, the processor and disk spend less time idle, or
not performing any useful work.
Reasons for allowing concurrency

2. Reduced waiting time.

 There may be a mix of transactions running on a system, some short
and some long.
 If transactions run serially, a short transaction may have to wait for a
preceding long transaction to complete, which can lead to
unpredictable delays in running a transaction.
 If the transactions are operating on different parts of the database, it
is better to let them run concurrently, sharing the CPU cycles and disk
accesses among them.
 Concurrent execution reduces the unpredictable delays in running
transactions.
 Moreover, it also reduces the average response time: the average
time for a transaction to be completed after it has been submitted.
Schedule

Sequences that indicate the chronological order in which

instructions of concurrent transactions are executed
a schedule for a set of transactions must consist of all
instructions of those transactions, and must preserve
the order in which the instructions appear in each
individual transaction.
Types of schedule
Serial schedule
Concurrent schedule
Serial Schedule

 Each serial schedule consists of a sequence of

instructions from various transactions, where
the instructions belonging to one single
transaction appear together in that schedule.
 Recalling a well-known formula from
combinatorics, we note that, for a set of n
transactions, there exist n factorial (n!)
different valid serial schedules.
 A Serial Schedule -1
Schedule- 1
• Suppose the current values of
accounts A and B are $1000 and
$2000, respectively.
• The final values of accounts A
and B, after the execution in
Figure 14.2 takes place, are
$855 and $2145, respectively.
• Thus, the total amount of
money in accounts A and B—
that is, the sum A + B—is
preserved after the execution of
both transactions.
Schedule 1—a serial schedule in
which T1 is followed by T2.
A Serial Schedule -2
Schedule- 2

A serial schedule where T2 is followed by T1

Concurrent Schedule
If two transactions are running concurrently, the operating
system may execute one transaction for a little while, then
perform a context switch, execute the second transaction
for some time, and then switch back to the first transaction
for some time, and so on.
Several execution sequences are possible, since the various
instructions from both transactions may now be
interleaved.
In general, it is not possible to predict exactly how many
instructions of a transaction will be executed before the
CPU switches to another transaction.
Concurrent Schedule -3
 Let T1 and T2 be the
transactions defined
previously. The
following schedule is
not a serial schedule,
but it is equivalent to
Schedule 1.
 In Schedules 1, 2 and
3, the sum A + B is
preserved.
Concurrent Schedule -4

The following concurrent

schedule does not preserve the
value of (A + B ).

Not all concurrent executions result in a correct

state.
SERIALIZABILITY

The effect of executing any concurrent

schedule must be same as the serial schedule,
for data consistency and integrity. This
requirement is called serializability.
That is, the schedule should, in some sense, be
equivalent to a serial schedule. Such schedules
are called serializable schedules.
Concurrency-control component of the
database system ensures serializability
Basic Assumption

Simplified view of transactions

 We ignore operations other than read and
write instructions
 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.
Types of Serializability
1. Conflict Serializability
After a series of exchange of non-conflicting
instructions, if we convert the concurrent
schedule into a serial schedule then it is called
“Conflict Serializable Schedule”.

2. View Serializability
Conflict Serializability
 Let us consider a schedule S in which there are two
consecutive instructions, Ii and Ij , of transactions Ti and
Tj , respectively (i ≠ j).
 If Ii and Ij refer to different data items, then we can
swap Ii and Ij without affecting the results of any
instruction in the schedule.
 However, if Ii and Ij refer to the same data item Q, then
the order of the two steps may matter.
 Since we are dealing with only read and write
instructions, there are four cases that we need to
consider:-
1. li = read(Q), lj = read(Q).
 The order of li and lj does not matter, since the same value of Q
is read by Ti and Tj , regardless of the order.
 li and lj don’t conflict.

2. li = read(Q), lj = write(Q).
 If Ii comes before lj , then Ti does not read the value of Q that is
written by Tj in instruction lj.
 If J comes before I, then Ti reads the value of Q that is written
by Tj. Thus, the order of I and J matters.
 They Conflict.
3. li = write(Q), lj = read(Q).
 They conflict for the same reason
4. li = write(Q), lj = write(Q). They conflict
Swap the read(B) instruction of T1 with the read(A) instruction of T2.
• Swap the write(B) instruction of T with the write(A) instruction of T .
1 2

• Swap the write(B) instruction of T with the read(A) instruction of T .

1 2
Schedule S
T1 T2
Read ( A )  
Write ( A )  
  Read ( A )
  Write ( A )
Read ( B )  
Write ( B )  
  Read ( B )
  Write ( B )
Schedule S Schedule S1

T1 T2 T1 T2

Read ( A )   Read ( A )  

Write ( A )   Write ( A )  

  Read ( A )   Read ( A )

  Write ( A )  Read ( B )
Read ( B )    Write
(A)
Write ( B )   Write ( B )  
  Read ( B )   Read ( B )
  Write ( B )   Write ( B )
Schedule S1 Schedule S2

T1 T2 T1 T2

Read ( A )   Read ( A )  

Write ( A )   Write ( A )  

  Read ( A )  Read ( B )

 Read ( B )   Read ( A )

 Write  Write
(A) (A)
Write ( B )   Write ( B )  

  Read ( B )   Read ( B )

  Write ( B )   Write ( B )
Schedule S2 Schedule S3

T1 T2 T1 T2
Read ( A )   Read ( A )  
Write ( A )   Write ( A )  

 Read ( B )  Read ( B )

  Read ( A )   Read ( A )
 Write Write ( B )  
(A)
Write ( B )    Write ( A )

  Read ( B )   Read ( B )

  Write ( B )   Write ( B )
Schedule S3 Schedule S4

T1 T2 T1 T2

Read ( A )   Read ( A )  

Write ( A )   Write ( A )  

 Read ( B )  Read ( B )

  Read ( A )  Write ( B )

Write ( B )    Read ( A )

 Write ( A )  Write ( A )

  Read ( B )   Read ( B )

  Write ( B )   Write ( B )
 Conflict Serializability
• 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.
• If a schedule S can be transformed into a schedule S´
by a series of swaps of nonconflicting instructions,
we say that S and S´ are conflict equivalent.
Conflict Serializability
Example of a schedule that is not conflict
serializable:

We are unable to swap instructions in the above

schedule to obtain
either the serial schedule < T3, T4 >, or the serial
schedule < T4, T3 >.
View Serializability
Let S and S´ be two schedules with the same set of transactions. S
and S´ are view equivalent if the following three conditions are
met, for each data item Q,
1. If in schedule S, transaction Ti reads the initial value of Q, then in
schedule S’ also transaction Ti must read the initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that value
was produced by transaction Tj (if any), then in schedule S’ also
transaction Ti must read the value of Q that was produced by the
same write(Q) operation of transaction Tj .
3. The transaction (if any) that performs the final write(Q) operation
in schedule S must also perform the final write(Q) operation in
schedule S’.
 Recoverable Schedules
We now need to address the effect of transaction failures during
concurrent execution.

• If a transaction Ti fails, for whatever reason, we need to undo

the effect of this transaction to ensure the atomicity property of
the transaction.
• In a system, that allows concurrent execution, the atomicity
property requires that any transaction Tj that is dependent on
Ti (that is, Tj has read data written by Ti) is also aborted.
• To achieve this, we need to place restrictions on the type of
schedules permitted in the system.
Recoverable Schedules
Consider the partial schedule in Figure, in which T7
is a transaction that performs only one instruction:
read(A).
We call this a partial schedule because we have not
included a commit or abort operation for T6.
Notice that T7 commits immediately after executing
Schedule-9
the read(A) instruction. A nonrecoverable
Thus, T7 commits while T6 is still in the active state. schedule
Now suppose that T6 fails before it commits.
T7 has read the value of data item A written by T6.
Therefore, we say that T7 is dependent on T6.
Because of this, we must abort T7 to ensure
atomicity. However, T7 has already committed and
cannot be aborted.
Thus, we have a situation where it is impossible to
recover correctly from the failure of T6.
Recoverability - Recoverable Schedules

If transaction Ti fails, it is rolled back.

Under concurrent environment, it is
necessary to ensure that any
transaction Tj depends on Ti must also
be rolled back.
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 .
• For the example of schedule-9 to
be recoverable, T would have to
7

delay committing until after T 6

commits.
Recoverable schedule

For pair of transactions Ti and Tj, if

Tj reads a data item returned by Ti
then Ti must commit before Tj,
called as recoverable Schedule.
 Cascade less schedules
 Even if a schedule is recoverable, to recover correctly from the failure of a
transaction Ti , we may have to roll back several transactions.

• As an illustration, consider the

partial schedule of Figure 14.15.
• Transaction T8 writes a value of A
that is read by transaction T9.
• Transaction T9 writes a value of A
that is read by transaction T10.
• Suppose that, at this point, T8 fails. T8
must be rolled back.
• Since T9 is dependent on T8, T9 must
be rolled back.
• Since T10 is dependent on T9, T10 must
be rolled back.
 Cascade less schedules
 Cascading Roll back - phenomenon, in which a single
transaction failure leads to a series of transaction
rollbacks, is called cascading rollback.
 To recover one transaction we need to roll back
several transactions, this is called cascading roll back.
 Cascading rollback is undesirable, since it leads to the
undoing of a significant amount of work. It is
desirable to restrict the schedules to those where
cascading rollbacks cannot occur. Such schedules are
called cascadeless schedules.
Cascade less schedules

Cascade less schedule

 Formally, 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 .
 It is easy to verify that every cascadeless
schedule is also recoverable.
Lock-based protocols

Shared mode
In shared mode, Transactions can only read the Data item.
Shared-lock is requested using lock-S instruction. This
mode is used when transaction wants to read data in the
database.
 
Exclusive mode
In Exclusive mode, Transactions can read as well as write
the Data item. Exclusive-lock is requested using lock-X
instruction.
Two phase locking protocol

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
 Schedule S
T1 T2 T3
LOCK-X(A)  
Read(A)
LOCK-S(B)
Read(B)

Write(A)
UNLOCK(A)
UNLOCK(B)
LOCK-X(A)
Read(A)
Write(A)
UNLOCK(A)
LOCK-S(A)
Read(A)
Time stamp based protocol

Each transaction Ti gets time stamp

TS(Ti) from system just before
execution
A transaction Tj, later will have new
Time Stamp. TS(Ti) < TS(Tj)
 Time Stamp can be implemented using

1. System Clock
2. Logical Counter

 Two Time Stamps

R-TS(Q) – Largest read time stamp

W-TS(Q) – Largest Write time stamp
 Timestamp-ordering protocol
Time stamp ordering protocol ensure that any conflicting
read and write operations are executed in timestamp
order.

1. Suppose Ti Reads
a. if TS(Ti) < W-TS(Q) Reject read
b. if TS(Ti) >= W-TS(Q) read operation executed
2. Suppose Ti Writes
a. if TS(Ti) < R-TS(Q) reject write
b. if TS(Ti) < W-TS(Q) reject Write
 Validation based protocol (optimistic)
 For many read transactions, concurrency control scheme
not needed, bcz it causes overhead.

 Use monitoring scheme

Read Phase – reads data item values, perform write on

local variables.
Validation Phase – check that write operation on db with
local variables will not cause any violation of serializability
Write Phase – writes to DB
 To perform validation we must know phases of
transaction, hence associate TimeStamp with
transaction Ti

 Start(Ti) - transaction started

 Validation(Ti) – finished read phase and started
validation phase
 Finish(Ti) – finish write phase
One of two conditions must hold for
transaction Tj if TS(Ti) < TS(Tj)
Finish(Ti) < Start (Tj)
Ti complete write phase before Tj starts
Validation phase
Start(Tj) < Finisth(Ti) < Validation (Tj)
 Deadlock
A system is said to be in deadlock
state, if every transaction is waiting
for other transaction to unlock the
database.
 Methods for dealing with deadlock
1. Deadlock Detection and Recovery
2. Deadlock prevention
 Deadlock detection - wait for graph
G(V,E)
V is set of transactions
E is set of Edges

Ti  Tj indicates Ti waiting for Tj to

unlock data.
wait for graph – no deadlock
wait for graph – deadlock
 Deadlock recovery steps
1. Detection of deadlock
2. Selection of victim
3. Rollback of victim
4. starvation
 Deadlock prevention
1. Wait & die - non pre-emptive
Ti request item locked by Tj
Ti can wait for Tj if it is older than Tj
2. Wound & wait - pre-emptive
Ti can wait for Tj if it is younger than
Tj
Finished….
Chapter 5 Topics

1. Query processing & Equivalence

Expression
2. Transaction
3. Concurrency Control
4. Dead Lock
Multiple Granularity Locking
 Intention locks allow a higher level node to be locked in S
or X mode without having to check all descendent nodes.

 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.
 Transaction Ti can lock a node Q, using the following rules:

 1. The lock compatibility matrix must be observed.

 2. The root of the tree must be locked first, and may be
locked in any mode.
 3. A node Q can be locked by Ti in S or IS mode only if the
parent of Q is currently locked by Ti in either IX or IS mode.
 4. A node Q can be locked by Ti in X, SIX, or IX mode only
if the parent of Q is currently locked by Ti in either IX or
SIX modes.
 5. Ti can lock a node only if it has not previously unlocked
any node (that is, Ti is two-phase).
 6. Ti can unlock a node Q only if none of the children of Q
are currently locked by Ti.
 Hidayat, 58
 Shruti - 47