Course Code: CS302

Database Management Systems

UNIT – IV

Transactions and Query Processing: Transaction Management - ACID properties,

Concurrency control – Schedules - Serializability, Locking Protocols,
Recoverability, Query Processing and optimization, Database Recovery methods.

Slide 1- 1
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Concurrent Execution in DBMS

 In a multi-user system, multiple users can access and use the same database
at one time, which is known as the concurrent execution of the database.
 It means that the same database is executed simultaneously on a multi-user
system by different users.
 Example:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 2

Problems with Concurrent Execution ?

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 3

Problems with Concurrent Execution

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 4

Problems with Concurrent Execution
 Lost Update Problems (W - W Conflict)
 Dirty Read Problems (W-R Conflict)
 Unrepeatable Read Problem (W-R Conflict)
 The Incorrect Summary Problem

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 5

Lost Update Problem.

 Occurs when two transactions update the same data item.

 But both read the same original value before update.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 6

Lost Update Problem.

 Example : Consider the below diagram where two transactions TX and TY, are
performed on the same account A where the balance of account A is $300.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 7

Dirty Read Problems (W-R Conflict)

 The dirty read problem occurs when one transaction updates an item of the
database, and somehow the transaction fails, and before the data gets
rollback, the updated database item is accessed by another transaction.
 There comes the Read-Write Conflict between both transactions.

 This occurs when one transaction T1 updates a database item X, which is

 accessed (read) by another transaction T2;
 Then T1 fails for some reason X was (read) by T2 before its value is changed
back (rolled back or UNDONE) after T1 fails

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 8

Dirty Read Problems (W-R Conflict)

 Example : Consider two transactions TX and TY in the below diagram

performing read/write operations on account A where the available balance
in account A is $300:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 9

Unrepeatable Read Problem (W-R Conflict)

 Also known as Inconsistent Retrievals Problem that occurs when in a

transaction, two different values are read for the same database item.

 A transaction T1 may read an item (say, available seats on a flight)

 Later
 T1 may read the same item again and get a different value because
another transaction T2 has updated the item (reserved seats on the
flight) between the two reads by T1

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 10

Unrepeatable Read Problem (W-R Conflict)

 Example : Consider two transactions, TX and TY, performing the read/write

operations on account A, having an available balance = $300. The diagram is
shown below:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 11

Unrepeatable Read Problem (W-R Conflict)
 It means that within the same transaction T
 X, it reads two different values of account A, i.e., $ 300 initially, and
 after updation made by transaction TY, it reads $400.
 It is an unrepeatable read and is therefore known as the Unrepeatable read problem.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 12

The Incorrect Summary Problem
 One transaction is calculating an aggregate summary function on a number of
records (for example, sum (total) of all bank account balances)
 While other transactions are updating some of these records (for example,
transferring a large amount between two accounts (Figure next slide)
 The aggregate function may read some values before they are updated and
others after they are updated.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 13

The Incorrect Summary Problem

 Example :

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 14

Concurrency Control
 Concurrency Control is the working concept that is required for controlling and
managing the concurrent execution of database operations and thus avoiding
the inconsistencies in the database.

 Thus, for maintaining the concurrency of the database, we have the

concurrency control protocols.

 Concurrency Control Protocols

 The concurrency control protocols ensure the atomicity, consistency, isolation,
durability and serializability of the concurrent execution of the database
transactions. Therefore, these protocols are categorized as:
 Lock Based Concurrency Control Protocol
 Time Stamp Concurrency Control Protocol
 Validation Based Concurrency Control Protocol

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 15

Lock-Based Protocol
 In this type of protocol, any transaction cannot read or write data until it
acquires an appropriate lock on it.

 A lock is a variable associated with a data item that describes the status of
the item with respect to possible operations that can be applied to it.
 There is one lock for each data item in the database.
 Locks are used as a means of synchronizing the access by concurrent
transactions to the database items.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 16

Binary Lock
 A Binary lock on a data item can either locked or unlocked states.
 Binary locks – two states Lock / unlock
 Mutual Exclusion
 Critical section

 Two operations, lock_item and unlock_item, are used with binary locking.
 A transaction requests access to an item X by first issuing a lock_item(X)
operation.
 When the transaction is completed using the item, it issues an unlock_item(X)
operation, which sets LOCK(X) back to 0 (unlocks the item) so that X may be
accessed by other transactions.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 17

Binary Lock

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 18

Types of Locks
 There are two types of lock:
1. Shared lock:
2. Exclusive lock:

1. Shared lock:
 It is also known as a Read-only lock.
 In a shared lock, the data item can only read by the transaction.
 It can be shared between the transactions because when the transaction holds a
lock, then it can't update the data on the data item.

2. Exclusive lock:
 In the exclusive lock, the data item can be both reads as well as written by the
transaction.
 This lock is exclusive, and in this lock, multiple transactions do not modify the
same data simultaneously.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 19
Lock-Based Protocol
Lock Compatibility Matrix –

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 20

Lock-Based Protocol
Lock Compatibility Matrix –

 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(X) on the item no other transaction may hold any
lock on the item.
 If a lock cannot be granted, the requesting transaction is made to wait till all
incompatible locks held by other transactions have been released. Then the lock
is granted.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 21

Lock-Based Protocol
Upgrade / Downgrade locks :
 A transaction that holds a lock on an item A is allowed under certain condition
to change the lock state from one state to another.

 Upgrade: S(A) can be upgraded to X(A)

 if Ti is the only transaction holding the S-lock on element A.

 Downgrade: We may downgrade X(A) to S(A) when we feel that we no

longer want to write on data-item A.
 As we were holding X-lock on A, we need not check any conditions.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 22

Types of Locking Protocol.

1. Simplistic lock protocol

2. Pre-claiming Lock Protocol
3. Two-phase locking (2PL)
4. Strict Two-phase locking (Strict-2PL)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 23

Simplistic lock protocol

 It is the simplest way of locking the data while transaction.

 Simplistic lock-based protocols allow all the transactions to get the lock on the
data before insert or delete or update on it.
 It will unlock the data item after completing the transaction.
 Example of a transaction performing locking:

T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 24

2. Pre-claiming Lock Protocol

 Pre-claiming Lock Protocols evaluate the transaction to list all the data items on
which they need locks.
 Before initiating an execution of the transaction, it requests DBMS for all the
lock on all those data items.
 If all the locks are granted then this protocol allows the transaction to begin.
 When the transaction is completed then it releases all the lock.
 If all the locks are not granted then this protocol allows the transaction to rolls
back and waits until all the locks are granted.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 25

2. Pre-claiming Lock Protocol

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 26

2. Pre-claiming Lock Protocol

Drawback:
Starvation
 Starvation is the situation when a transaction needs to wait for an indefinite
period to acquire a lock.
 Following are the reasons for Starvation:
 When waiting scheme for locked items is not properly managed
 In the case of resource leak
 The same transaction is selected as a victim repeatedly

Deadlock
 Deadlock refers to a specific situation where two or more processes are waiting
for each other to release a resource or more than two processes are waiting for
the resource in a circular chain.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 27

Two-phase Locking Protocol

 Two Phase Locking Protocol also known as 2PL protocol is a method of

concurrency control in DBMS that ensures serializability by applying a lock to
the transaction data which blocks other transactions to access the same data
simultaneously.

 The two-phase locking protocol divides the execution phase of the transaction
into three parts.
 In the first part, when the execution of the transaction starts, it seeks
permission for the lock it requires.
 In the second part, the transaction acquires all the locks. The third phase
is started as soon as the transaction releases its first lock.
 In the third phase, the transaction cannot demand any new locks. It only
releases the acquired locks.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 28

Two-phase Locking Protocol

 If Locking as well as the Unlocking can be performed in 2 phases, a transaction

is considered to follow the Two-Phase Locking protocol.

 The two phases are known as the growing and shrinking phases.
 Growing Phase: In this phase, we can acquire new locks on data items, but

none of these locks can be released.

 Shrinking Phase: In this phase, the existing locks can be released, but no

new locks can be obtained.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 29

Two-phase Locking Protocol

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 30

Two-phase Locking Protocol - Example

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 31

Two-phase Locking Protocol - Example

Transaction T1:
 Growing phase: from step 1-3
 Shrinking phase: from step 5-7
 Lock point: at 3

Transaction T2:
 Growing phase: from step 2-6
 Shrinking phase: from step 8-9
 Lock point: at 6

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 32

Two-phase Locking Protocol - Example

 Transactions that do not obey two phase locking.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 33

Two-phase Locking Protocol - Example

 Transactions T1′ and T2′ follow the two-phase locking protocol

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 34

Two-phase Locking Protocol - Example

Problem :
 The likelihood of establishing deadlocks is one bad result.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 35

4. Strict Two-phase locking (Strict-2PL)

 The first phase of Strict-2PL is similar to 2PL.

 In the first phase, after acquiring all the locks, the transaction continues to
execute normally.
 The only difference between 2PL and strict 2PL is that Strict-2PL does not
release a lock after using it.
 and then it releases all the locks at a time. Strict-2PL waits until the whole
transaction to commit,
 Strict-2PL protocol does not have shrinking phase of lock release.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 36

4. Strict Two-phase locking (Strict-2PL)

•It does not have cascading abort as 2PL does.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 37

Precedence Graph For Testing Serializability

 If a precedence graph contains a single edge Ti → Tj, then all the instructions
of Ti are executed before the first instruction of Tj is executed.

 If a precedence graph for schedule S contains a cycle,

 then S is non-serializable.

 If the precedence graph has no cycle,

 then S is known as serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 38

Precedence Graph For Testing Serializability

Example: Consider the schedule S :

 S : r1(x) r1(y) w2(x) w1(x) r2(y)

Creating Precedence graph:

 Make two nodes corresponding to Transaction T 1 and T2.

 S : r1(x) r1(y) w2(x) w1(x) r2(y)

 For the pair r1(x) w2(x),
 where r1(x) happens before w2(x),
 draw an edge from T1 to T2

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 39

Precedence Graph For Testing Serializability

 S : r1(x) r1(y) w2(x) w1(x) r2(y)

 For the pair w2(x) w1(x),
 where w2(x) happens before w1(x),
 draw an edge from T2 to T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 40

Precedence Graph For Testing Serializability – Example:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 41

Precedence Graph For Testing Serializability

Example: Explanation:
Read(A): In T1, no subsequent writes to A, so no new edges
Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 42

Precedence Graph For Testing Serializability – Example:

Precedence graph for schedule S1:

T1

T2 T3

The precedence graph for schedule S1 contains a cycle that's why Schedule S1
is non-serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 43

Precedence Graph For Testing Serializability – Example:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 44

Precedence Graph For Testing Serializability

Example: Explanation:
Read(A): In T4,no subsequent writes to A, so no new edges
Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): A is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 45

Precedence Graph For Testing Serializability – Example:

Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why

ScheduleS2 is serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 46

Types of serializability:

 Depending on the type of schedules, there are two types of serializability:

 Conflict Serializable Schedule

 View Serializable Schedule

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 47

 Conflict Serializability

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 48

Conflict Serializable Schedule

 A schedule is called conflict serializable

 if it can be transformed into a serial schedule
 by swapping non-conflicting operations.
 or
 The schedule will be a conflict serializable if it is conflict equivalent to a serial
schedule.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 49

Conflict Serializable Schedule

Conflicting operations:
 Two operations are said to be conflicting if all conditions satisfy:
 They belong to different transaction

 They operate on same data item

 At Least one of them is a write operation

Example - Conflicting operations

 Conflicting operations pair (R1(A), W2(A)) because they belong to two
different transactions on same data item A and one of them is write operation.
 Similarly, (W1(A), W2(A)) and (W1(A), R2(A)) pairs are also conflicting.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 50

Conflict Serializable Schedule

Example - Conflicting operations

 Here, S1 ≠ S2. That means it is conflict.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 51

Conflict Serializable Schedule

Example – Non Conflicting operations:

 On the other hand, (R1(A), W2(B)) pair is non-conflicting because they
operate on different data item.
 Similarly, ((W1(A), W2(B)) pair is non-conflicting.

 Here, S1 = S2. That means it is non-conflict.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 52

Conflict Serializable Schedule - Example

Example
 Consider the following schedule:
 S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)

 we can get two transactions of schedule S1 as:

 T1: R1(A), W1(A), R1(B), W1(B)
 T2: R2(A), W2(A), R2(B), W2(B)

 Possible Serial Schedules are:

T1->T2 or T2->T1

 Swapping non-conflicting operations

 R2(A) and R1(B) in S1, the schedule becomes,

 S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)

 S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 53
Conflict Serializable Schedule - Example

Example
 Similarly, swapping non-conflicting operations W2(A) and W1(B) in S11,
the schedule becomes
 S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)

 S12: R1(A), W1(A), R1(B), W1(B), R2(A), W2(A), R2(B), W2(B)

 S12 is a serial schedule in which all operations of T1 are performed before

starting any operation of T2.
 Since S1 has been transformed into a serial schedule S12 by swapping non-
conflicting operations of S1
 S1 is conflict serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 54

Conflict Serializable Schedule - Example

Example

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 55

Conflict Serializable Schedule - Example

Example - After swapping of non-conflict operations, the schedule S1 becomes:

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

Since, S1 is conflict serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 56

View Serializability Schedule

 A schedule will view serializable if it is view equivalent to a serial schedule.

 If a schedule is conflict serializable, then it will be view serializable.
 The view serializable which does not conflict serializable contains blind writes.

View Equivalent
 Two schedules S1 and S2 are said to be view equivalent if they satisfy the
following conditions:
1. Initial Read
2. Updated Read
3. Final Write

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 57

View Serializability Schedule

1. Initial Read
 An initial read of both schedules must be the same.
 Suppose two schedule S1 and S2.
 In schedule S1, if a transaction T1 is reading the data item A, then in S2,
transaction T1 should also read A.

 Above two schedules are view equivalent because Initial read operation in S1 is
done by T1 and in S2 it is also done by T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 58

View Serializability Schedule

2. Updated Read
 In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti
should read A which is updated by Tj.

 Above two schedules are not view equal because, in S1, T3 is reading A
updated by T2 and in S2, T3 is reading A updated by T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 59

View Serializability Schedule

3. Final Write
 A final write must be the same between both the schedules.
 In schedule S1, if a transaction T1 updates A at last then in S2, final writes
operations should also be done by T1.


 Above two schedules is view equal because Final write operation in S1 is done
by T3 and in S2, the final write operation is also done by T3.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 60

View Serializability Schedule - Example

Example : Consider the following schedule S

 With 3 transactions, the total number of possible schedule

 = 3! = 6
 S1 = <T1 T2 T3>
 S2 = <T1 T3 T2>
 S3 = <T2 T3 T1>
 S4 = <T2 T1 T3>
 S5 = <T3 T1 T2>
 S6 = <T3 T2 T1>

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 61

View Serializability Schedule - Example

 Example : Taking first schedule S1 and Compare with schedule S

 schedule S

 schedule S1

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 62

View Serializability Schedule - Example

 Example : Taking first schedule S1 and Compare with schedule S

Step 1: final updation on data items
 In both schedules S and S1, there is no read except the initial read that's why we
don't need to check that condition.
Step 2: Initial Read
 The initial read operation in S is done by T1 and in S1, it is also done by T1.
Step 3: Final Write
 The final write operation in S is done by T3 and in S1, it is also done by T3. So,
S and S1 are view Equivalent.

The first schedule S1 satisfies all three conditions, so we don't need to check
another schedule.
 Hence, view equivalent serial schedule is:
T1 → T2 → T3
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 63