Scheduling in DBMS

Scheduling

Definition

Scheduling is the technique of preserving the order of the

operations from one transaction to another while executing
such concurrent transactions. A series of operations from
one transaction to another transaction is known as
a schedule.
 Scheduling
What is Scheduling, and why is it required?
• Transaction are a set of instructions that perform operations on
databases.
• When multiple transactions are running concurrently, then a
sequence is needed in which the operations are to be
performed because at a time, only one operation can be
performed on the database.
• This sequence of operations is known as Schedule, and this
process is known as Scheduling.
 Scheduling
What is Scheduling, and why is it required?
• When multiple transactions execute simultaneously in an
unmanageable manner, then it might lead to several problems,
which are known as concurrency problems. In order to
overcome these problems, scheduling is required.
 Scheduling

Types of Schedules

There are mainly two types of scheduling

1. Serial Schedule

2. Non-serial Schedule
Types of Schedules
Types of Schedules
Types of Schedules
 Types of Schedules - Serial Schedule

• All the transactions are executed serially one after the

other. In serial Schedule, a transaction does not
start execution until the currently running
transaction finishes execution.
• This type of execution of the transaction is also known
as non-interleaved execution.
• Serial Schedule are always recoverable, cascades,
strict and consistent.
• A serial schedule always gives the correct result.
 Types of Schedules - Serial Schedule

Example:
 Types of Schedules - Serial Schedule
Example:
Consider two transactions T1 and T2 shown above, which
perform some operations. If it has no interleaving of
operations, then there are the following two possible
outcomes.

If n = number of transactions, then a number of serial

schedules possible = n!.

Therefore, for the above 2 transactions, a total number of serial

schedules possible = 2.
 Types of Schedules - Non-serial Schedule
Non-serial Schedule
• In a non-serial Schedule, multiple transactions execute
concurrently/simultaneously.
• In the Non-Serial Schedule, the other transaction
proceeds without the completion of the previous
transaction.
• All the transaction operations are interleaved or
mixed with each other.
• Non-serial schedules are NOT always recoverable,
cascades, strict and consistent.
 Types of Schedules - Non-serial Schedule
Example:
 Types of Schedules - Non-serial Schedule
Example:
In this Schedule, there are two transactions, T1 and T2, executing
concurrently. The operations of T1 and T2 are interleaved. So,
this Schedule is an example of a Non-Serial Schedule.

Total number of non-serial schedules = Total number of

schedules – Total number of serial schedules
Serializability in DBMS
 Serializability

• Serializability is a concept that helps to identify

which non-serial schedules are correct and will
maintain the consistency of the database.
• A serializable schedule always leaves the database in a
consistent state.
• A serial schedule is always a serializable
schedule because, in a serial Schedule, a transaction
only starts when the other transaction has finished
execution.
 Serializability

• Serializability is a concept that helps to identify

which non-serial schedules are correct and will
maintain the consistency of the database.
• A serializable schedule always leaves the database in a
consistent state.
• A serial schedule is always a serializable
schedule because, in a serial Schedule, a transaction
only starts when the other transaction has finished
execution.
 Serializability

Difference between Serial Schedule and Serializable Schedule

 Serializability

Types of Serializability:

• Conflict Serializability

• View Serializability
 Serializability

Conflict Serializability
A schedule is called conflict serializable if it can be
transformed into a serial schedule by swapping non-
conflicting operations.

An operations pair become conflicting if all conditions satisfy:

1. Both belong to separate transactions.
2. They have the same data item.
3. They contain at least one write operation.
 Serializability

Example:
• Read i(x) read j(x) - non conflict read-read operation

• Read i(x) write j(x) - conflict read-write operation.

• Write i(x) read j(x) - conflict write-read operation.

• Write i(x) write j(x) - conflict write-write operation.

Serializability
 Serializability

View Serializability
• A schedule is viewed 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 with
serializable, contains blind writes.
 Serializability

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
 Serializability
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.

Note: 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.
 Serializability

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.

Note: 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.
 Serializability
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.

Note: 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.
Non-Serializability in DBMS
 Non-Serializability
• A non-serial schedule that is not serializable is called a
non-serializable schedule.
• Non-serializable schedules may/may not be consistent
or recoverable.

Non-serializable Schedule is divided into types:

1. Recoverable Schedule
2. Non-recoverable Schedule
 Non-Serializability
Recoverable Schedule
• A schedule is recoverable if each transaction commits
only after all the transactions from which it has read
have committed.
• In other words, if some transaction Ty reads a value that
has been updated/written by some other transaction Tx,
then the commit of Ty must occur after the commit of Tx.
 Non-Serializability
Recoverable Schedule
 Non-Serializability
Non-Recoverable Schedule
• If a transaction reads the value of an operation from
an uncommitted transaction and commits before the
transaction from where it has read the value, then
such a schedule is called Non-Recoverable schedule.
• A non-recoverable schedule means when there is a
system failure, we may not be able to recover to a
consistent database state.
• If the commit operation of Ti doesn't occur before
the commit operation of Tj, it is non-recoverable.
 Non-Serializability
Non-Recoverable Schedule
Concurrency Control in DBMS
 Concurrency Control
• Concurrency control concept comes under the
Transaction in database management system (DBMS).
• It is a procedure in DBMS which helps us for the
management of two simultaneous processes to execute
without conflicts between each other, these conflicts
occur in multi user systems.
• It is required to increase time efficiency. Concurrency
control required to maintain consistency data.
 Concurrency Control
Advantages
The advantages of concurrency control are as follows :
• Waiting time will be decreased.
• Response time will decrease.
• Resource utilization will increase.
• System performance & Efficiency is increased.
 Concurrency Control
Main problems in using Concurrency
The problems which arise while using concurrency
are as follows :
• Lost Update Problems (W - W Conflict)
• Dirty Read Problems (W-R Conflict)
• Unrepeatable Read Problem (W-R Conflict)
 Concurrency Control

Lost Update Problems (W - W Conflict)

• The problem occurs when two different database
transactions perform the read/write operations on the
same database items in an interleaved manner (i.e.,
concurrent execution) that makes the values of the items
incorrect hence making the database inconsistent.
 Concurrency Control
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.
 Concurrency Control
• At time t1, transaction TX reads the value of account A, i.e., $300

• At time t2, transaction TX deducts $50 from account A that becomes

$250 (only deducted and not updated/write).
• Alternately, at time t3, transaction TY reads the value of account A

that will be $300 only because TX didn't update the value yet.

• At time t4, transaction TY adds $100 to account A that becomes

$400 (only added but not updated/write).
• At time t6, transaction TX writes the value of account A that will be

updated as $250 only, as TY didn't update the value yet.

• Similarly, at time t7, transaction TY writes the values of account A, so

it will write as done at time t4 that will be $400. It means the value
 Concurrency Control
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.
 Concurrency Control
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:
 Concurrency Control
• At time t1, transaction TX reads the value of account A, i.e., $300.

• At time t2, transaction TX adds $50 to account A that becomes $350.

• At time t3, transaction TX writes the updated value in account A, i.e.,

$350.
• Then at time t4, transaction TY reads account A that will be read as
$350.
• Then at time t5, transaction TX rollbacks due to server problem, and
the value changes back to $300 (as initially).
• But the value for account A remains $350 for transaction TY as
committed, which is the dirty read and therefore known as the Dirty
Read Problem.
 Concurrency Control
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.
 Concurrency Control
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:
 Concurrency Control
• At time t1, transaction TX reads the value from account A, i.e., $300.

• At time t2, transaction TY reads the value from account A, i.e., $300.

• At time t3, transaction TY updates the value of account A by adding $100

to the available balance, and then it becomes $400.
• At time t4, transaction TY writes the updated value, i.e., $400.

• After that, at time t5, transaction TX reads the available value of account
A, and that will be read as $400.
• It means that within the same transaction TX, 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.
 Concurrency Control
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
 Concurrency Control
Lock Based Concurrency Control Protocol
In Lock Based protocol any transaction cannot read or
write data until it acquires an appropriate lock on it.

There are two types of lock:

• Shared lock
• Exclusive lock
 Concurrency Control
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.
 Concurrency Control

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.
 Concurrency Control
There are four types of lock protocols available
1. Simplistic lock protocol
2. Pre-claiming Lock Protocol
3. Two-phase locking (2PL)
4. Strict Two-phase locking (Strict-2PL)
 Concurrency Control
1. 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.
 Concurrency Control
2. Pre-claiming Lock Protocol
 Concurrency Control
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.
 Concurrency Control
3. Two-phase locking (2PL)
• 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.
 Concurrency Control
3. Two-phase locking (2PL)
 Concurrency Control
3. Two-phase locking (2PL)
There are two phases of 2PL:
Growing phase:
In the growing phase, a new lock on the data item may
be acquired by the transaction, but none can be released.

Shrinking phase:
In the shrinking phase, existing lock held by the
transaction may be released, but no new locks can be
acquired.
 Concurrency Control

In the below example, if lock conversion is allowed then

the following phase can happen:
• Upgrading of lock (from S(a) to X (a)) is allowed in
growing phase.

• Downgrading of lock (from X(a) to S(a)) must be done

in shrinking phase.
Concurrency Control
 Concurrency Control

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
 Concurrency Control

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.
• Strict-2PL waits until the whole transaction to commit, and
then it releases all the locks at a time.
• Strict-2PL protocol does not have shrinking phase of lock
release.
 Concurrency Control

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

Deadlock in DBMS