Chapter-10

Transaction Processing
and Concurrency
Control
Presented by : Er. LaIi Manandhar
Assistant Senior Lecturer
Everest Engineering College
 Transaction
◈ Collection of operations such as insertion, deletion,
modifications etc that form a single logical unit of work are
called transactions.
◈ A transaction is a unit of program execution that accesses and
possibly updates various data items.
◈ A transaction operations must be done entirely (commit) or
aborted (Rollback), no intermediated state are acceptable.
◈ During transaction execution, the database may be
temporarily inconsistent however when the transaction
completes successfully i.e. commits, the database must be
consistent.
◈ After a transaction commits, the changes it has made to the
◈ Transaction Processing Systems are the systems, which includes
large size database and allows many users to use same database
concurrently.
◈ For example: AirIine reservation system.
◈ Example:
◈ Transaction to transfer Rs 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)
 State of Transaction
◈ After the transaction starts execution, it changes state.
◈ The state of a transaction is defined as the current activity of
that transaction.
◈ Each transaction may have one of the following states
explained below.
1. Active: It is the initial state; the transaction stays in this state
while it is executing.
2. Partially Committed: After the final statement has been executed.
3. Failed: After the discovery that normal execution can no longer
proceed.
4. Aborted: After the transaction has been rolled back and the
database has been restored to the state prior to the start of
transaction.
5. Committed: A transaction that completes its execution
successfully is said to be committed.
 ACID properties of Transaction
◈ To ensure data integrity, database system maintains the following
properties of transaction.
1. Atomicity:
A transaction is an atomic unit of processing. It is either performed
completely or not performed at all.
At the end of transaction, the update made by the transaction will
be accessible to other transactions.
Atomicity is maintained in the presence of deadlock, software
failure, disk failure etc.
2. Consistency:
The consistency property of transaction impIies that if
database was
 in consistent state before the initiation of a transaction, then at the
end of the transaction the database will also be in a consistent state.
This means that a transaction can’t break the rules or integrity
constraints of the database.
3. Isolation:
The isolation property of a transaction indicates that the steps of
operations performed by a transaction should be isolated from
other transaction i.e. the execution of a transaction should not be
interfered by any other transaction being executed simultaneously.
Intermediate results of any transaction must be hidden from other
concurrently executing transactions.
4. DurabiIity:
The durabiIity property of transaction indicates that the changes
made to the database by a committed transaction must persist in the
database.
These changes must not be lost by any kind of failure.
DurabiIity also refers to the abiIity of the system to recover
committed transaction updates if the system or storage media fails.
 Schedules
◈
◈
◈ In the above example, schedule1 and schedule2 are serial
schedule because in schedule1 Transaction T1 is followed by
Transaction T2 and in schedule2 Transaction T2 is followed by
Transaction T1.
◈ Schedule3 is non-serial schedule because there is interleaving of
operations between transactions T1 and T2.
◈ However the schedule3 is equivalent schedule to schedule1 and
schedule2 since the sum (A+B) is preserved.
◈ Schedule4 is confIict schedule because it doesn’t preserve the
value of (A+B)
 Serializability
◈ Serial schedule are generally considered unacceptable in practice
because in serial schedule, if a transaction waits for I/O operations
to complete, it make waste of CPU time making while other
transactions are ready for execution.
◈ So interleaving i.e. non serial schedule could improve the use of
CPU cycle.
◈ But some non-serial schedule produces erroneous result while
some produce correct result. So this introduces the concept of
serializabiIity.
◈ A concurrent execution of N transaction is called serializable, if
the execution is computationally equivalent to a serial execution.
◈ When more than one transactions is being executed
concurrently, we must have serializabiIity in order to have same
effect on the database as same serial execution does.
◈ There are two types of serializability.
1. Conflict serializability
2. View serializability
 1. ConfIict serializability
◈ If two operations in a schedule satisfy all these three conditions
then operations are said to be confIict.
i. They belong to different transaction.
ii. They access the same item.
iii. At least one of the operations is write operation.
◈ Instructions Ii and Ij of transactions Ti and Tj respectively, confIict
if and only if there exists some item Q accessed by both Ii and Ij ,
and at least one of these instructions wrote Q.
 1. Ii = read(Q), Ij = read(Q). Ii and Ij don’t confIict.
2. Ii = read(Q), Ij = write(Q). They confIict.
3. Ii = write(Q), Ij = read(Q). They confIict
4. Ii = write(Q), Ij = write(Q). They confIict
◈ If a schedule S can be transformed into a schedule S´ by a series of
swaps of non-confIicting instructions, we say that S and S´ are
confIict equivalent.
◈ So a schedule S is confIict serializability if it is conflict equivalent
to a serial schedule
◈ Schedule1 is conflict seriazability since we can swap instructions
(T1, T2) or (T2,T1) to get and equivalent serial schedule but
schedule2 is not as we are unable to swap the instruction in the
above schedule to obtain either the serial schedule (t1,t2) or (t2,
t1).
 2. View serializability
◈ Two schedules S1 and S2 having same set of instructions are said
to be view equivalent if the following conditions are met.
1. If the transaction Ti in S1 reads an initial value for object X, so does
the transaction Ti in S2.
2. If the transaction Ti in S1 reads the value written by transaction Tj in
S1 for object X, so does the transaction Ti in S2.
3. If the transaction Ti in S1 is the final transaction to write the value for
an object X, so is the transaction Ti in S2.
◈ So a schedule is said to be view serializability if it is view
equivalent to a serial schedule. Schedule3 in page no 2, is schedule
which is both view serializability and conflict serializability.
◈ Also every conflict- serializability schedule is also a view
serializability but there are some view serializability that are not
conflict serializability.
◈ Below figure shows a schedule which is view serializability but
not conflict serializability.
 Testing of serializability
◈
◈ If the graph doesn’t contain a cycle, it is called as conflict
serializable else non serializable. i.e. A schedule is conflict
serializable if and only if its precedence graph is acyclic.
◈ Example:
1. Let us consider a schedule as given below.
 Concurrently Control Technique
◈ Concurrency control is the process of managing simultaneous
operations Iike inserts, updates, deletes on the database without
having them interfere with one another.
◈ Simply concurrency control is the management of concurrent
transaction execution.
◈ DBMS implements concurrency control technique to ensure
seriaIizabiIity and isolation of transaction in order to guard the
consistency and integrity of database.
◈ There are several concurrency control techniques which are
explained below.
 1. Lock based protocols
◈ One way to ensure seriaIizabiIity is to require that data items be
accessed in mutually exclusive manner i.e. while one transaction
is accessing a data item s, no other transaction can modify that
data items.
◈ In this scheme, each data item has a loc k associated with it. When
a transaction T wants to access the data item, it first examines the
associated lock.
◈ If no other transaction hold the lock, the lock scheduler locks the
data items for transaction T.
◈ Now if any other transaction Ti wants to access the same data item
then Ti has to wait until T releases the lock.
◈ So any transaction must obtain a read lock or write lock on data
◈ Mode of locking
1. Shared Lock(S) or Read Lock
If a transaction T has shared mode lock on data item Q then,
◈ T can read them but not update Q.
◈ Any other transactions can also obtain read lock on same
data item Q but not write lock.
2. Exclusive Lock(X) or Write Lock
If a transaction T has exclusive mode lock on a data item Q
then,
◈ T can both read and update the Q.
◈ No other transaction can obtain either of read or write lock.
◈ Based on these locking modes, we can define a compatibiIity
matrix.

◈ If A and B are two arbitrary locking modes, if transaction T1 hold

A lock on data item X and another transaction T2 request a B lock
on the same data item.
◈ Then if the transaction T2 gets the permission to lock X in B mode
then we say that B mode is compatible to A mode.
◈ Shared mode is compatible with shared mode but not with
exclusive mode.
◈ At any time several shared lock can be held simultaneously on a
particular data item.
◈ A subsequent exclusive mode locking request has to wait until
the currently held shared mode locks are released.
◈ For example: let us consider we have two transaction as below.

T1: Read (Y) T2: Read (X)

Read (X) Read (Y)
X=X+Y X=X - Y
Write (X) Write (X)
◈ Using locking, this transaction can be written as
T1: Readlock ( Y) T2: Writelock (X)
Read (Y) Read (X)
Unlock (Y) Readlock(Y)
Writelock (X) Read (Y)
Read (X) Unlock (Y)
X=X+Y X=X-Y
Write (X) Write (X)
Unlock (X) Unlock (X)
 2. Two Phase Locking Protocol (2PL)
◈ If transactions running concurrently are allowed to acquire and
release locks as read and updated, there is a danger that incorrect
result may be produced.
◈ So to overcome this problem two phase locking scheme is used.
◈ In this scheme transactions make lock and unlock requests in two
phases.
1. Growing phase
2. Shrinking phase
◈ In growing phase, a transaction may obtain locks but may not
release any lock.
◈ Here the no. of locks increases from zero to maximum for the
transaction.
◈ In shrinking phase, a transaction releases locks but may not
obtain any new locks.
◈ Here the no. of locks decreases from maximum to zero.
◈ The schedule S2 wouldn’t lead to incorrect result, but both
transactions are blocked waiting for each other resulting
deadlock situations.
◈ Deadlock occurs because of circular wait conditions involving
two or more transactions as above i.e. T2 holding B and
requesting A held by T1, T1 holding A and requesting B held by T1.
◈ So in 2pl, we need a deadlock detection mechanism and a
technique to resolve the deadlock once it occurs.
 Types
A. Conservative or Static 2PL:
According to this scheme, a transaction locks all data items before
beginning its operations and unlocks those data items only after
executing its last operations i.e. pre-declare all the locks before its
execution.
It often degrades the system performance by unnecessary delaying
other transactions which want to access some of the data item
locked by the transaction.
The locking protocol is deadlock free but is difficult to use in
practice.
Example:

Readlock (X)
Readlock(Y)
Writelock(Z)
Read (X)
Read (Y)
Z=X+Y
Write (Z)
Unlock (X)
Unlock (Y)
Unlock (Z)
B. Dynamic 2PL:
◈ In this scheme, a transaction locks on a data items immediately before it
is accesses. All the locks are released immediately after the last step of
transaction. Example:
Readlock (X)
Read(X)
Readlock (Y)
Read (Y)
Writelock (Z)
Z=X+Y
Write (Z)
Unlock (X)
Unlock (Y)
Unlock (Z)
C. Strict 2PL:
In this protocol, a transaction does not release any of its write lock
until it commits or aborts.
D. Rigorous 2PL:
In this protocol, a transaction does not release any of write lock and
read lock until it commits or aborts.
 Deadlock
◈ Deadlock is a set of blocked transactions each holding a resource
and waiting to acquire a resource held by another process in the
set.
◈ The simplest example of deadlock is given below.
1. Transaction T1 request resource A and receive it.
2. Transaction T2 request resource B and receive it.
3. Transaction T1 request resource B and is queued up waiting the
release of B by transaction T2.
4. Transaction T2 request resource A and is queued up waiting the
release of A by transaction T1.
 Condition of deadlock
◈ We can say a deadlock is occurred if these four conditions occur
simultaneously.
◈ Mutual Exclusion:
Only one transaction at a time can use a resource.
◈ Hold and wait:
A transaction holding at least one resource is waiting to acquire
additional resources held by other transactions.
◈ No preemption:
A resource can be released only voluntarily by the transaction
holding it after the transaction completed its task.
◈ Circular wait:
There exist a set {T1, T2,……….TN} of waiting process such that T1 is
waiting for a resource that is held by T2, T2 is waiting for a resource
held by T3 and finally TN is waiting for resource held by T1.
 Deadlock Prevention
◈ We can prevent the deadlock by
1. Preventing mutual exclusion by making the entire sharable data
item sharable. This doesn’t create any problem for read operation
but may lead to serious problem for write operation.
2. No cycIic wait should occur.
3. Resources should be preempted.
4. A transaction may not request a resource if it is holding another
resource.
5. Perform transaction rollback instead of waiting for a lock.
 Deadlock Detection
◈ Whenever a transaction is blocked by a lock, every time the DBMS
build and analyze a waits- for-graph.
◈ If there is a cycle in the wait-for-graph, then a deadlock is said to
exist in the system.
◈ Once deadlock has been detected, it must be resolved.
◈ The most common resolution technique is that one transaction in
the wait-for-graph is selected as a victim and is rolled back and
restarted and the other transaction continues.
 Deadlock Recovery
◈ When deadlock is detected, the system must recover from the
deadlock.
◈ Some of the approaches for breaking a deadlock are Iisted below.
1. Simply Rollback one or more Transactions (victim) in order to
break the circular wait. In this, two method can be appIied.
a) Rollback all deadlock transaction: This will break the deadlock
cycle but at a loss of lots of computation, since transactions may
have computed for a long period of time and the result of the
partial computation must be discarded and recomputed later.
b) Rollback one process at a time: This will rollback one
transaction at a time until a deadlock cycle is eIiminated. With
each rollback, this requires invoking deadlock detection
 Deadlock Recovery
2. Resource Preemption In this, preempt some resource from
transactions and allocate it to other transactions till the deadlock
cycle is broken.
◈ It involve the following issues.
a) We must determine which resource and which transaction are to be
preempted. If a transaction has completed 95% of its execution, it should not
be our choice for preemption.
b) The process from which the resource is preempted should be rolled back
and restarted.
c) Starvation should be avoided. Starvation happens if same transaction is
chosen as victim .i.e. resource are always preempted from same transaction
as a result this transaction never completes its task.
 Time Stamp Based Ordering Scheme
◈
◈ The protocol manages concurrent execution such that the
time-stamps determine the seriaIizabiIity order.
◈ In order to assure such behavior, the protocol maintains for each
data Q two timestamp values:
– W-timestamp(Q) is the largest time-stamp of any transaction that
executed write(Q) successfully.
– R-timestamp(Q) is the largest time-stamp of any transaction that
executed read(Q) successfully.
◈ The timestamp ordering protocol ensures that any confIicting
read and write operations are executed in timestamp order.
◈ 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 max(Rtimestamp(Q), TS(Ti)).
◈ 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).
 Multiple Granularity
◈ Granularity is the size of data item being locked.
◈ It is considered as the major factor concurrency control because it
can effect the performance of concurrency and recovery.
◈ Because, if the granularity of a data item is very large then the
overhead of the lock is very low.
◈ For example, if we select the data item as whole database, then a
transaction T while accessing even a small portion of database will
lock the whole database and no concurrent access by other
transactions would be allowed.
◈ Multiple granularity allows data item to be of various size and
define a hierarchy of data granularities where the small
granularities are nested within the larger one. It can be
◈ The highest level represent the entire database.
◈ Below it are node of type area.
◈ Each area in turn has node of type file as its children. Finally each file
has node of type records.
◈ In addition to shared lock and exclusive lock, there are three more
additional lock modes with it.
1. intention-shared (IS): If a node is locked in IS mode then it indicates expIicit
locking at a lower level of the tree but only with shared locks.
2. intention-exclusive (IX): indicates expIicit locking at a lower level with
exclusive or shared locks.
3. shared and intention-exclusive (SIX): the sub-tree rooted by that node is
locked expIicitly in shared mode and expIicit locking is being done at a lower
level with exclusive-mode locks.
Intention locks allow a higher level node to be locked in S or X mode without
having to check all descendent nodes.