DATA BASE

DB

MANAGEMENT
UNIT-4 M

Presented By
S Mohammad Bilal J
SYSTEM Assistant professor
Department I.T
VCE
 UNIT-4

01 ✓Transaction concept ✓ Transaction states

02
✓ ACID properties

✓View Serializability
03 ✓ Serializability, 04
✓Testing for Serializability,
✓Conflict Serializability

✓Recoverability ✓Cascade less and

05 06
✓schedules-serial schedules ✓Recoverable schedules

✓ Concurrency Control ✓time-stamp based protocols,

07 08
✓Lock based protocols ✓Deadlock handling.
 Transaction concept
✓ Transaction refers to execution of any user program in dbms.
✓ It also referred to as an event that occur on a database with read/write operation.
✓ A transaction is a unit of program execution that accesses and possibly updates various data items.
✓ Basic transaction operations:
✓ read (X): Performs the reading operation of data item X from the database.
✓ write (X): Performs the writing operation of data item X to the database.
✓ During transaction execution the database may be inconsistent.
✓ When the transaction is committed, the database must be consistent.
✓ Two main issues to deal with:
✓ Failures, (e.g. hardware failures and system crashes)
✓ Concurrency, for simultaneous execution of multiple transaction.
 Transaction states
✓ Every transaction undergoes several states in its execution.
✓ A transaction can be in any one of the following states:
i. Start
ii. Partially Committed
iii. Committed
iv. Failed
v. Aborted Or Terminate
 Transaction states
i. Active:
✓ This is the first state of transaction and here the transaction is being executed.
✓ For example, updating or inserting or deleting a record is done here. But it is still not saved to the database.
✓ When we say transaction it will have set of small steps, and those steps will be executed here.
ii. Partially Committed:
✓ This is also an execution phase where last step in the transaction is executed. But data is still not saved to the
database.
iii. Committed:
✓ In this state, all the transactions are permanently saved to the database.
✓ This step is the last step of a transaction, if it executes without fail.
 Transaction states
iv. Failed:
✓ If a transaction cannot proceed to the execution state because of the failure of the system or database, then the
transaction is said to be in failed state.
v. Aborted:
✓ If a transaction is failed to execute, then the database recovery system will make sure that the database is in its
previous consistent state.
✓ If not, it brings the database to consistent state by aborting or rolling back the transaction.
✓ If the transaction fails in the middle, all the executed transactions are rolled back to it consistent state before
executing the same or other transaction.
✓ Once the transaction is aborted it is either restarted to execute again or fully killed by the DBMS.
 Transaction Schedules
Schedule:
✓ It refers to the list of actions to be executed by transaction.
✓ A schedule is a process of grouping the transactions into one and executing them in a predefined order.
Example:
S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)
T1- R1(A), W1(A), R1(B), W1(B)
T2-R2(A), W2(A), R2(B), W2(B)

2.1.2 Types of schedules

 Transaction Schedules
✓ Schedule of actions can be classified into 2 types.
i. Serializable schedule/serial schedule.
ii. Concurrent schedule.
✓ S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)
✓ S2: R1(A), W1(A), R1(B), W1(B), R2(B), W2(B), R2(A), W2(A)
Serial schedule
✓ In the serial schedule the transactions are allowed to execute one after the other ensuring correctness of data.
✓ A schedule is called serial schedule, if the transactions in the schedule are defined to execute one after the
other.
Concurrent schedule
✓ Concurrent schedule allows the transaction to be executed in interleaved manner of execution.
✓ T1 T2 T1 T2 T1 ….
 Transaction Schedules
Complete schedule
✓ It is a schedule of transactions where each transaction is committed before terminating.
✓ The example is shown below where transactions T1 and T2 terminates after committing the transactions.

T1 T2
A=1000
Read(A)
A=A+100
Write(A) Read(A)
B=A-100
Write(B)
Commit
Read(B)
Write(B)
Commit
 Properties of Transaction (Acid Properties)
✓ To ensure consistency, completeness of the database in scenario of concurrent access, system failure, the following
ACID properties can be enforced on to database.
i . Atomicity
ii. Consistency
iii. Isolation
Iv. Durability
 i. Atomicity
✓ This property states that either all of the instructions with in a transaction must be executed or none of them
should be executed.
✓ It involves following two operations.
i. Abort : If a transaction aborts, changes made to database are not visible.
ii. Commit : If a transaction commits, changes made are visible.
✓ Atomicity is also known as the ‘All or nothing rule’.
Example:
✓ Consider the following transaction T consisting of T1 and T2: Transfer of 100 from account X to account Y.

✓ If the transaction fails after completion of T1 but before completion of

T2.Then amount has been deducted from X but not added to Y.

✓ This results in an inconsistent database state.

✓ Therefore, the entire transaction must be executed in order to ensure

correctness of database state.
 ii. Consistency
✓ The database must remain in consistence state even after performing any kind of transaction ensuring correctness
of the database.
✓ Each transaction, run by itself and must preserve the consistency of the database.
✓ Ensuring this property of a transaction is the responsibility of the application programmer.

✓ Referring to the example,

✓ The total amount before and after the transaction must be maintained.
✓ Total before T occurs = 500 + 200 = 700.
✓ Total after T occurs = 400 + 300 = 700.
✓ Therefore, database is consistent.

✓ Inconsistency occurs in case T1 completes but T2 fails. As a result, T is

incomplete.
 iii. 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.

✓ If we execute a particular transaction in isolation (or) together with other transaction in multiprogramming
environment, the transaction should give same result in any case.

✓ When executing multiple transactions concurrently and trying to access shared resources the system should
create an order such that the only one transaction can access the shared resource at the same time & release it
after completion of it’s execution for other transaction.

✓ This property ensures that multiple transactions can occur concurrently without leading to inconsistency of
database state.

✓ Changes occurring in a particular transaction will not be visible to any other transaction until that particular change
in that transaction is written to memory or has been committed.

Note: To achieve isolation you should use locking mechanism among shared resources.
 iii. Isolation
✓ example: Let X= 500, Y = 500. Consider two transactions T and T”.

✓ Suppose T has been executed till Read (Y) and then T’’ starts.
✓ As a result , interleaving of operations takes place due to which T’’ reads correct value of X but incorrect value of Y
and sum computed by T’’: (X+Y = 50, 000+500=50, 500) is thus not consistent with the sum at end of transaction: T:
(X+Y = 50, 000 + 450 = 50, 450).
✓ This results in database inconsistency, due to a loss of 50 units. Hence, transactions must take place in isolation
and changes should be visible only after a they have been made to the main memory.

✓ It is the responsibility of Concurrency Control Manager.

 iv. Durability
✓ After a transaction completes successfully, the changes it has made to the database persist, even if there are
system failures.
✓ This property states that once after the transaction is completed the changes that made should be permanent &
should be recoverable even after system crash/power failure.

✓ This property ensures that once the transaction has completed execution, the updates and modifications to the
database are stored in and written to disk and they persist even is system failure occurs.
✓ It is the responsibility of Recovery Manager.
 Serializability
✓ Basic Assumption is serial execution of transactions preserves database consistency.
✓ Serializability is related to schedules and transactions.
✓ Schedule is a set of transactions, and a transaction is a set of instructions used to perform any logical operations in
terms of databases.
✓ A concurrent schedule is serializable if it is equivalent to a serial schedule.
✓ Serializability of schedules ensures that a non-serial schedule is equivalent to a serial schedule.
✓ It helps in maintaining the transactions to execute serially without interleaving one another.
✓ To test the serializability of a schedule, we can use Serialization Graph or Precedence Graph.
✓ A Precedence Graph is a Directed Graph of the entire transactions of a schedule.
✓ It can be defined as a Graph G(V, E) consisting of a set of directed-edges E = {E1, E2, E3, ..., En} and a set of vertices
V = {V1, V2, V3, ...,Vn}.
✓ The set of edges contains one of the two operations - READ, WRITE performed by a certain transaction.
 Serializability
✓ If there is a cycle present in the graph then the schedule is non-serializable because the cycle indicates that one
transaction is dependent on the other transaction.
✓ On the other hand, no-cycle means that the non-serial schedule is serializable.
What is a conflicting pair in transactions?

✓ Two operations inside a schedule are called conflicting if they meet these three conditions:

i. They belong to two different transactions.

ii. They are working on the same data piece.

iii. One of them is performing the WRITE operation.

✓ let’s take two transactions on data: "a". The conflicting pairs are:

T1 T2
READ(a) WRITE(a)
WRITE(a) WRITE(a)
WRITE(a) READ(a)
 Serializability
Note: There can never be a read-read conflict as there is no change in the data.
 Conflict Serializability
✓ A non-serial schedule is a conflict serializable if, after performing some swapping on the non-conflicting operation
results in a serial schedule.

✓ It is the process of checking the non-serial schedule and an equivalent serial schedule. This process of checking is
called Conflict Serializability.

✓ It is tedious to use if we have many operations and transactions as it requires a lot of swapping.

✓ For checking, we will use the Precedence Graph technique.

✓ First, we will check conflicting pairs operations(read-write, write-read, and write-write) and then form directed
edges between those conflicting pair transactions.

✓ If we can find a loop in the graph, then the schedule is non-conflicting serializable otherwise it is surely a
conflicting serializable schedule.
 Conflict Serializability
Example-1: A schedule "S" having three transactions t1, t2, and t3 working simultaneously. Check Whether S is Conflict
Serializable or Not?
T1 T2 T3
R(x)
R(y)
R(y)
W(y)
W(x)
W(x)
R(x)
W(x)
✓ As there is no loop in the graph, it is a conflict serializable schedule as well as a serial schedule.
✓ Since it is a serial schedule, we can detect the order of transactions as well.
✓ The order of the Transactions: t1 will execute first as there is no incoming edge on T1. (i.e., In degree=0)
✓ T3 will execute second as it depends on T1 only.
✓ T2 will execute at last as it depends on both T1 and T3.
✓ So, order of its equivalent serial schedule is: T1 --> T3 --> T2
 Conflict Serializability
Example-2: A schedule "S" having three transactions t1, t2, and t3 working simultaneously. Check Whether S is Conflict
Serializable or Not?

T1 T2 T3
R(x)
R(z)
W(z)
R(y)
R(y)
W(y)
W(x)
W(z)
W(x)

✓ As the cycle is formed, the transactions cannot be serializable.

Example-3: Check Whether S is Conflict Serializable or Not?

Step-1:

✓ List all the conflicting operations and the dependency

between the transactions.
₋ W1(B) , W2(B) (T1 → T2)
₋ W1(B) , W3(B) (T1 → T3)
₋ W1(B) , W4(B) (T1 → T4)
₋ W2(B) , W3(B) (T2 → T3)
₋ W2(B) , W4(B) (T2 → T4)
₋ W3(B) , W4(B) (T3 → T4)

Step-2:

✓ Draw the precedence graph.

Step-3:

✓ Clearly, there exists no cycle in the precedence graph.

✓ Therefore, the given schedule S is conflict serializable.

Example-4: Check Whether S is Conflict Serializable or Not?

Step-1:
List all the conflicting operations and determine the dependency
between the transactions-
₋ R1(A) , W2(A) (T1 → T2)
₋ R2(A) , W1(A) (T2 → T1)
₋ W1(A) , W2(A) (T1 → T2)
₋ R1(B) , W2(B) (T1 → T2)
₋ R2(B) , W1(B) (T2 → T1)
Step-2:

✓ Draw the precedence graph.

Step-3:

✓ Clearly, there exists a cycle in the precedence graph.

✓ Therefore, the given schedule S is not conflict serializable.

 View Serializability
✓ There may be some schedules that are not Conflict-Serializable but still gives a consistent result because Conflict-
Serializability becomes limited when the Precedence Graph of a schedule contains a loop/cycle.

✓ But, what if a schedule’s precedence graph contains a cycle/loop and is giving consistent result .

✓ So, to address such cases we brought the concept of View-Serializability because we did not want to confine only
to Conflict-Serializability.

✓ A schedule is said to be View-Serializable if it is view equivalent to a Serial Schedule (where no interleaving of

transactions is possible).

✓ View Serializability is a process to find out that a given schedule is view serializable or not.

✓ To check whether a given schedule is view serializable, we need to check whether the given schedule is View
Equivalent or not.
 View Serializability
View Equivalent:

✓ Lets learn how to check whether the two schedules are view equivalent.

✓ Two schedules T1 and T2 are said to be view equivalent, if they satisfy all the following conditions:

i. Initial Read

ii. Final Write

iii. Update Read

 View Serializability
i. Initial Read:

✓ Initial read of each data item in transactions must match in both schedules.

✓ For example, if transaction T1 reads a data item X before transaction T2 in schedule S1 then

✓ In schedule S2, T1 should read X before T2.

✓ Read vs Initial Read: There may be confusion by the term initial read. Here initial read means the first read
operation on a data item, for example, a data item X can be read multiple times in a schedule but the first read
operation on X is called the initial read.
 View Serializability
ii. Final Write:

✓ Final write operations on each data item must match in both the schedules.

✓ For example, a data item X is last written by Transaction T1 in schedule S1.

✓ In S2, the last write operation on X should be performed by the transaction T1.
 View Serializability
iii. Update Read:

✓ If in schedule S1, the transaction T1 is reading a data item updated by T2 then in schedule S2, T1 should read the
value after the write operation of T2 on same data item.

✓ For example, In schedule S1, T3 performs a read operation on A after the write operation on A by T2 then in S2, T3
should read the A after T2 performs write on A.
 View Serializability
Problem-1 : Prove whether the given schedule is View-Serializable or not?

✓ 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>
 View Serializability
Step 1: Initial Read S
✓ The initial read operation in S is done by T1 and in S1 it is also done by T1 .

Step 2: Final Write

✓ The final write operation in S is done by T3 and in S1, it is also done by T3.

Step 3: Updated Read

S1
✓ 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.

✓ 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

Problem-2 : Prove whether the given schedule is View-Serializable or not?

Step-1: Initial Read

✓ In schedule S1, transaction T1 first reads the data item X. In S2 also

transaction T1 first reads the data item X.

✓ Lets check for Y. In schedule S1, transaction T1 first reads the data item Y. In
S2 also the first read operation on Y is performed by T1.

✓ We checked for both data items X & Y and the initial read condition is
satisfied in S1 & S2.
Step-2: Final Write

✓ In schedule S1, the final write operation on X is done by transaction T2. In S2 also transaction T2 performs the final
write on X.

✓ Lets check for Y. In schedule S1, the final write operation on Y is done by transaction T2. In schedule S2, final write
on Y is done by T2.

✓ We checked for both data items X & Y and the final write condition is satisfied in S1 & S2.
 View Serializability
Step-3: Update Read:

✓ In S1, transaction T2 reads the value of X, written by T1. In S2, the same
transaction T2 reads the X after it is written by T1.

✓ In S1, transaction T2 reads the value of Y, written by T1. In S2, the same
transaction T2 reads the value of Y after it is updated by T1.

✓ The update read condition is also satisfied for both the schedules.

✓ Since all the three conditions are satisfied , which means S1 and S2 are view equivalent.

✓ Also, as we know that the schedule S2 is the serial schedule of S1, thus we can say that the schedule S1 is view
serializable schedule.
 View Serializability
Method-2 :
✓ If the given schedule is non-conflict serializable, then it may or may not be view serializable. So we need to look at
the below cases.

✓ Blind write : Performing the Writing operation (updation), without reading operation, such write operation is
known as a blind write.

✓ If no blind write exists, then the schedule must be a non-View-Serializable schedule.

✓ If there exists any blind write, then, in that case, the schedule may or may not be view serializable.

✓ If it does not contain any blind-write, we can surely state that the schedule would not be View-Serializable.
Problem-3:Check whether the given schedule S is view serializable or not?

Solution-We know, if a schedule is conflict serializable, the it is surely view

serializable.

✓ So, let us check whether the given schedule is conflict serializable or not.

Step-01:

✓ List all the conflicting operations and determine the dependency

between the transactions-

R1(A) , W3(A) (T1 → T3)

R2(A) , W3(A) (T2 → T3)

R2(A) , W1(A) (T2 → T1)

W3(A) , W1(A) (T3 → T1)

 View Serializability
Step-02:

✓ Draw the precedence graph.

✓ Clearly, there exists a cycle in the precedence graph.

✓ Therefore, the given schedule S is not conflict serializable.

Now,

✓ Since, the given schedule S is not conflict serializable, so, it may or may
not be view serializable.

✓ To check whether S is view serializable or not, let us use another

method( blind writes).
Checking for Blind Writes:

✓ There exists a blind write W3 (A) in the given schedule S.

✓ Therefore, the given schedule S may or may not be view serializable.

✓ Now,Let us derive the dependencies and then draw a dependency

graph.

✓ Drawing a Dependency Graph-

▪ T1 firstly reads A and T3 firstly updates A. So, T1 must execute

before T3.Thus, we get the dependency T1 → T3.

▪ Final updation on A is made by the transaction T1.So, T1 must

execute after all other transactions.Thus, we get the
dependency (T2, T3) → T1.
•Clearly, there exists a cycle in the dependency
▪ There exists no write-read sequence.
graph.
Now, let us draw a dependency graph using these dependencies-
•Thus, we conclude that the given schedule S
is not view serializable.
Problem-4:Check whether the given schedule S is view serializable or not. If
yes, then give the serial schedule.

S : R1(A) , W2(A) , R3(A) , W1(A) , W3(A)

Step-01:

✓ List all the conflicting operations and determine the dependency between
the transactions-

R1(A) , W2(A) (T1 → T2)

R1(A) , W3(A) (T1 → T3)

W2(A) , R3(A) (T2 → T3)

W2(A) , W1(A) (T2 → T1)

W2(A) , W3(A) (T2 → T3)

R3(A) , W1(A) (T3 → T1)

W1(A) , W3(A) (T1 → T3)

 View Serializability
Step-02:

✓ Draw the precedence graph-

✓ Clearly, there exists a cycle in the precedence graph.

✓ Therefore, the given schedule S is not conflict serializable.

Now,

✓ Since, the given schedule S is not conflict serializable, so, it may or may
not be view serializable.

✓ To check whether S is view serializable or not, let us use another method.

Let us check for blind writes.

Checking for Blind Writes:

✓ There exists a blind write W2 (A) in the given schedule S.

✓ Let us derive the dependencies and then draw a dependency graph.

Drawing a Dependency Graph-

✓ T1 firstly reads A and T2 firstly updates A.

✓ So, T1 must execute before T2.

✓ Thus, we get the dependency T1 → T2.

✓ Final updation on A is made by the transaction T3.

✓ So, T3 must execute after all other transactions.

✓ Thus, we get the dependency (T1, T2) → T3.

✓ From write-read sequence, we get the dependency T2 → T3
•Clearly, there exists no cycle in the
dependency graph.
•Therefore, the given schedule S is view
serializable.
•The serialization order T1 → T2 → T3.
 Recoverability
✓ A non-serial schedule which is not serializable is called as a non-serializable schedule.

✓ A non-serializable schedule is not guaranteed to produce the consistent database values.

✓ Non-serializable schedules-may or may not be consistent

✓ may or may not be recoverable

What is a Recoverable Schedule?

✓ A schedule that can be successfully rolled back in case of any failure is known as recoverable Schedule.

What is an Irrecoverable Schedule?

✓ A schedule that cannot be rolled back because some transactions already used COMMIT to make the changes
permanent in database and these transactions have used values produced by the failed transactions. These types
of schedules are called irrecoverable schedules.
 i.Irrecoverable Schedules
A transaction performs a dirty read operation from an uncommitted transaction and commits before the transaction
from which it has read the value then such a schedule is known as an Irrecoverable Schedule.
Example:
Consider the following schedule
Here,
✓ T2 performs a dirty read operation.
✓ T2 commits before T1.
✓ T1 fails later and roll backs.
✓ The value that T2 read now stands to be incorrect.
✓ T2 can not recover since it has already committed.
 ii. Recoverable Schedules
✓ A transaction performs a dirty read operation from an uncommitted transaction and its commit operation is
delayed till the uncommitted transaction either commits or roll backs then such a schedule is known as a
Recoverable Schedule.
✓ The commit operation of the transaction that performs the dirty read is delayed.
✓ This ensures that it still has a chance to recover if the uncommitted transaction fails later.
Example-:

✓ T2 performs a dirty read operation.

✓ The commit operation of T2 is delayed till T1 commits or roll backs.

✓ T1 commits later.

✓ T2 is now allowed to commit.

✓ In case, T1 would have failed, T2 has a chance to recover by rolling back.

 Recoverability
How to Check Whether a Schedule is Recoverable or Irrecoverable?

Method-01:

✓ All conflict serializable schedules are recoverable.

✓ All recoverable schedules may or may not be conflict serializable.

Method-02:

✓ Check if there exists any dirty read operation.(Reading from an uncommitted transaction is called as a dirty read)

✓ If there does not exist any dirty read operation, then the schedule is surely recoverable.

✓ If there exists any dirty read operation, then the schedule may or may not be recoverable.

✓ If there exists a dirty read operation, then follow the following cases:
 Recoverability
Types of Recoverable Schedules:
 i. Cascading Schedule
✓ If in a schedule, failure of one transaction causes several other dependent transactions to rollback or abort, then such a schedule
is called as a Cascading Schedule or Cascading Rollback or Cascading Abort.

Example:

✓ Transaction T2 depends on transaction T1.

✓ Transaction T3 depends on transaction T2.

✓ Transaction T4 depends on transaction T3.

In this schedule,

✓ The failure of transaction T1 causes the transaction T2 to rollback.

✓ The rollback of transaction T2 causes the transaction T3 to rollback.

✓ The rollback of transaction T3 causes the transaction T4 to rollback.

Such a rollback is called as a Cascading Rollback.

NOTE-If the transactions T2, T3 and T4 would have committed before the failure of transaction T1, then the schedule would have
been irrecoverable.
 ii. Cascadeless Schedule
✓ 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 Cascade-less Schedule.

✓ Cascadeless schedule allows only committed read operations.

Example:

✓ Cascade-less schedule allows only committed read operations.

✓ However, it allows uncommitted write operations.

 iii. Strict Schedule
✓ If in a schedule, a transaction is neither allowed to read nor write a data item until the last transaction that has
written it is committed or aborted, then such a schedule is called as a Strict Schedule.

✓ Strict schedule allows only committed read and write operations.

✓ Clearly, strict schedule implements more restrictions than cascadeless schedule.

✓ All strict schedules are cascadeless schedules.

✓ All cascadeless schedules are not strict schedules.

 Concurrency Control
✓ In case of concurrent instruction executions to preserve atomicity, isolation and serializability, we use ‘lock-based’
protocols.

✓ A lock is kind of a mechanism that ensures that the integrity of data is maintained. It does that, by locking the data
while a transaction is running, any other transaction cannot read or write the data until it acquires the appropriate
lock.

✓ Types of Locks:

i. Binary locks

ii. Shared and exclusive locks

Binary Locks :

✓ A lock on a data item can be in two states; it is either locked or unlocked.

 Concurrency Control
Shared Locks:

✓ which are often denoted as lock-S(), is defined as locks that provide Read-Only access to the information associated
with them.

✓ Whenever a shared lock is used on a database, it can be read by several users, but these users who are reading the
the data items will not have permission to edit it or make any changes to the data items.

✓ A shared lock, also known as a read lock.

Exclusive Lock:

✓ This lock allows both the read and write operation, Once this lock is placed on the data no other lock (shared or
Exclusive) can be placed on the data until Exclusive lock is released.

✓ The other name for an exclusive lock is write lock.

✓ which are often denoted as X-lock( ) or lock-x( )

 Concurrency Control
Lock Compatibility Matrix:

✓ Lock Compatibility Matrix controls whether multiple transactions can acquire locks on the same resource at the
same time.

✓ If a resource is already locked by another transaction, then a new lock request can be granted only if the mode of
the requested lock is compatible with the mode of the existing lock.

✓ Any number of transactions can hold shared locks on an item, but if any transaction holds an exclusive lock on
item, no other transaction may hold any lock on the item.
 Concurrency Control
Upgrading And Downgrading of Locks:

✓ If a transaction is holding an exclusive lock over an object .It can simply downgrade from exclusive lock to shared
lock after completion of its updation.

✓ Similarly a shared lock can be upgraded to exclusive lock on particular data item. when there is no other
transaction is holding exclusive lock on same data item
 Locking Protocols
✓ Locking protocols are 2-types,they are:

i. Simple Lock Based Protocol

ii. 2-Phase Locking Protocol

✓ Conservative (or) pre-claim locking protocol.

✓ Strict 2 phase locking protocol

✓ Rigorous 2 phase locking protocol

i. Simple lock based protocol:

✓ It allow transactions to obtain a lock on every object before a 'write' operation is performed.

✓ Transactions may unlock the data item after completing the ‘write’ operation.

✓ Problems with simple locking are:

A. Deadlocks

B. Starvation
 2-Phase Locking Protocol
✓ This locking protocol divides the execution phase of a transaction into two
parts.

✓ The First part is where the transaction acquires all the locks.

✓ As soon as the transaction releases its first lock, the second phase starts. In
this phase the transaction cannot demand any new locks; it only releases the
acquired locks.

✓ This protocol can be divided into two phases:

1. Growing Phase : a transaction obtains locks, but may not release

any lock.

2. Shrinking Phase: a transaction may release locks, but may not

obtain any lock.
 2-Phase Locking Protocol
✓ Two-phase locking has two phases, one is growing, where all the locks are being acquired by the transaction; and
the second phase is shrinking, where the locks held by the transaction are being released.

What is LOCK POINT?

✓ The Point at which the growing phase ends, i.e., when a transaction takes the final lock it needs to carry on its
work

✓ Types of Two – Phase Locking Protocol

i. Conservative Two – Phase Locking Protocol

ii. Strict Two – Phase Locking Protocol

iii. Rigorous Two – Phase Locking Protocol

 i. Conservative Two – Phase Locking Protocol
✓ Conservative protocols evaluate their operations and find list of data items on which they need locks.

✓ Before initiating an execution, the transaction requests the system for all the locks it needs.

✓ If all the locks are granted, the transaction executes and releases all the locks when all its operations are over.

✓ If all the locks are not granted, the transaction rolls back and waits until all the locks are granted.

✓ Since in the schedule the lock on a is released by T1, it is possible for the
transaction T2 to acquire the lock on a.

✓ Now the transaction T2 reads the value of a which was written by

transaction T1.

✓ This implies that if the transaction T1 aborts, the transaction T2 must be

aborted for consistency purposes.

✓ It mean that even though a conservative two phase protocol is used, the
schedules may not necesssarily be cascadeless.
 ii. Strict Two – Phase Locking Protocol
✓ In this method all Exclusive(X) locks held by the transaction be
released after the Transaction Commits.

✓ The first phase of Strict-2PL is same as 2PL i.e. when the

transaction starts executing, it seeks permission for the locks it
requires and acquiring all the locks in the first phase, the
transaction continues to execute normally.

✓ In second phase Strict-2PL does not release a lock after using it. It
releases only all exclusive locks after a transaction is committed.

✓ It guarantees cascadeless recoverability.

 iii. Rigorous Two – Phase Locking Protocol

✓ This protocol requires that all the share and exclusive locks to be held until
the transaction commits.

✓ It releases all the locks including shared and exclusive locks after committing
the transactions.

✓ Same as Strict 2PL but Hold all locks until the transaction has already
successfully committed or aborted.

✓ There is no deadlock.
 Locking Protocols
Cascading Roll Back in 2PL:
S no. T1 T2 T3
✓ Because of Write(R1) in T1 and after that, Read(R1) in T2 and
1 Lock-X(R1)
Read(R1) in T3, there is a dirty read which means the data written 2 Read(R1)

by transaction T1 is being read by transaction T2 and T3. 3 Write(R1)

4 Lock-S(R2) LP
✓ So if T1 Rollback, T2 and T3 also have to rollback, causing 5 Read(R2)
cascading Rollback. So cascading Rollback is possible in a two- Unlock-R1,
6
Unlock-R2
phase locking protocol.
7 Lock-X(R1) LP
✓ In the above transaction, LP denotes Lock Point. 8 Read(R1)
9 Write(R1)
✓ Before the lock point in all three transactions, T1, T2, and T3, 10 Unlock-R1
there is a growing phase in transactions, respectively, and after LP, 11 Lock-S(R1) LP

the shrinking phase starts. 12 Read-R1

 Locking Protocols
S.no T1 T2

1 Lock-X(R1) Lock-X(R2)

2 Read(R1) Read(R2)

3 Lock-X(R2) Lock-X(R1)

Deadlock in 2PL:

✓ In the above transaction in step 3, T1 cannot execute the exclusive lock in R2 as the Exclusive lock is already
obtained by transaction T2 in step 1.

✓ Also, in step 3, the Exclusive lock on R1 cannot be executed by T2 as T1 has already applied the Exclusive lock on
R1.

✓ So, if we draw a wait-for graph, we can see that T1 waits for R2 and T2 waits for R1, which creates conflict, and the
waiting time never ends, which leads to a deadlock.
 Timestamp based Ordering Protocol
✓ Timestamp ordering protocol maintains the order of transaction based on their timestamps.

✓ A timestamp is a unique identifier that is being created by the DBMS when a transaction enters into the system.
This timestamp can be based on the system clock or a logical counter maintained in the system.

✓ Timestamp helps identifying the older transactions and gives them higher priority compared to the newer
transactions. This make sure that none of the transactions are pending for a longer period of time.

✓ This protocol also maintains the timestamps for the last read and last write on a data.

✓ The timestamp of the transaction T1 is denoted as TS(T1) .

Example:

✓ let’s say an old transaction T1 timestamp is TS(T1) and a new transaction T2 enters into the system, timestamp
assigned to T2 is TS(T2).

✓ Here TS(T1) < TS(T2) so the T1 has the higher priority because its timestamp is less than timestamp of T2.
 Timestamp based Ordering Protocol
Read time-stamp of data-item:

✓ It is denoted as R_TS(A)

✓ R_TS(A) is the largest or youngest timestamp of a transaction that executed the operation read(A)
successfully.

Write time-stamp of data-item:

✓ It is denoted as W_TS(A) .

✓ W_TS(A) is the largest or youngest timestamp of a transaction that executed the operation write(A)
successfully.
 Timestamp based Ordering Protocol
Basic Timestamp ordering protocol works as follows:

1. Check the following condition whenever a transaction Ti issues a Read (X) operation:

✓ If W_TS(X) >TS(Ti) then the operation is rejected.

✓ If W_TS(X) <= TS(Ti) then the operation is executed.

✓ Timestamps of all the data items are updated.

2. Check the following condition whenever a transaction Ti issues a Write(X) operation:

✓ If TS(Ti) < R_TS(X) then the operation is rejected.

✓ If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back otherwise the operation is
executed.
 Timestamp based Ordering Protocol
Whenever a Transaction Tn issues a Read(A) operation, this
protocol checks the following conditions:
Whenever a Transaction Tn issues a Write(A) operation,
If ( W_TS(A) > TS(Tn) ) this protocol checks the following conditions:
{
abort and reject Tn If ( R_TS(A) > TS(Tn) or W_TS(A) > TS(Tn) )
}
else {
{ abort and rollback the transaction Tn
Read(A) operation of Tn
update the timestamp R_TS(A) }
} else
{
Write(A) operation of Tn
update W_TS(A) to TS(Tn)
}
 Timestamp based Ordering Protocol
Advantages of Timestamp based protocol:

✓ Schedules managed using timestamp based protocol are serializable just like the two phase protocols

✓ Since older transactions are given priority which means no transaction has to wait for longer period of time that
makes this protocol free from deadlock.

Thomas' Write Rule

✓ This rule states if TS(Ti) < W_TS(A), then the operation is rejected and Ti is rolled back.

✓ Time-stamp ordering rules can be modified to make the schedule view serializable. Instead of making Ti rolled
back, the 'write' operation itself is ignored and continue the remaining operations.
 ‘U’ T

K H

N A