APEX INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

Database Management System (21CST-232)

Serializability
Faculty: Deepinder Kaur(E9237)

Serializability & Concurrency Control DISCOVER . LEARN . EMPOWER

1
DBMS: Course Objectives
COURSE OBJECTIVES
The Course aims to:
• Understand database system concepts and design databases for different applications
and to acquire the knowledge on DBMS and RDBMS.
• Implement and understand different types of DDL, DML and DCL statements.
• Understand transaction concepts related to databases and recovery/backup
techniques required for the proper storage of data.

By: Deepinder Kaur (E9237) 2

COURSE OUTCOMES

On completion of this course, the students shall be able to:-

Understand the database concept, system architecture and role of database
CO1
administrator
CO2 Design database for an organization using relational model
Apply relational algebra and relational calculus to query the database of
CO3
organization
CO4 Implement the package, procedures and triggers
CO5 Understand the concept of transaction processing and concurrency  control

3
Schedule
• Schedule, as the name suggests, is a process of lining the
transactions and executing them one by one.
• When there are multiple transactions that are running in a
concurrent manner and the order of operation is needed to be
set so that the operations do not overlap each other,
• Scheduling is brought into play and the transactions are
timed accordingly.
 Serial Schedule
• where one transaction is executed
completely before starting another
transaction.
• For example: 
1.Execute all the operations of T1 which
was followed by all the operations of
T2.
2.Execute all the operations of T1 which
was followed by all the operations of
T2.
 Non Serial Schedule
• If interleaving of operations is allowed,
then there will be non-serial schedule.
• It contains many possible orders in
which the system can execute the
individual operations of the
transactions.
 Serializable Schedule
• The serializability of schedules is used to find non-serial schedules that
allow the transaction to execute concurrently without interfering with
one another.
• It identifies which schedules are correct when executions of the
transaction have interleaving of their operations.
• A non-serial schedule will be serializable if its result is equal to the
result of its transactions executed serially.
Serializability
• Basic Assumption – Each transaction preserves database
consistency.
• Thus, serial execution of a set of transactions preserves
database consistency.
• A (possibly concurrent) schedule is serializable if it is
equivalent to a serial schedule. Different forms of
schedule equivalence give rise to the notions of:
1. conflict serializability
2. view serializability
Serializability-Testing
• Serialization Graph is used to test the Serializability of a
schedule.
1.Create a node Ti → Tj if Ti executes write (Q) before Tj
executes read (Q).
2.Create a node Ti → Tj if Ti executes read (Q) before Tj
executes write (Q).
3.Create a node Ti → Tj if Ti executes write (Q) before Tj
executes write (Q).
Serializability-Testing
• 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.
Serializability-Testing
• 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
 Serializability-Testing

The precedence graph for schedule S1 contains a

cycle that's why Schedule S1 is non-serializable.
Conflicting Instructions
• Let li and lj be two Instructions of transactions Ti and Tj
respectively. Instructions li and lj conflict if and only if there exists
some item Q accessed by both li and lj, and at least one of these
instructions wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
• Intuitively, a conflict between li and lj forces a (logical) temporal
order between them.
• If li and lj are consecutive in a schedule and they do not conflict, their results
would remain the same even if they had been interchanged in the schedule.
Conflict Serializability
• A schedule is called conflict serializability if after
swapping of non-conflicting operations, it can transform
into a serial schedule.
• The schedule will be a conflict serializable if it is
conflict equivalent to a serial schedule.
• The two operations 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.
Conflict Serializability (Cont.)
• Schedule 3 can be transformed into Schedule 6 -- a serial schedule where T2
follows T1, by a series of swaps of non-conflicting instructions. Therefore,
Schedule 3 is conflict serializable.

Schedule 3 Schedule 6
Conflict Serializability (Cont.)
• Example of a schedule that is not conflict serializable:

• We are unable to swap instructions in the above schedule

to obtain either the serial schedule < T3, T4 >, or the serial
schedule < T4, T3 >.
View Serializability
• 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.
Three conditions for view equivalence:
1.First read should be performed by same transaction.
2.Last Write should be performed by same transaction.
3.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.
View Serializability
• Let S and S´ be two schedules with the same set of transactions. S and S´ are
view equivalent if the following three conditions are met, for each data
item Q,
1. If in schedule S, transaction Ti reads the initial value of Q, then in
schedule S’ also transaction Ti must read the initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that value was
produced by transaction Tj (if any), then in schedule S’ also
transaction Ti must read the value of Q that was produced by the
same write(Q) operation of transaction Tj .
3. The transaction (if any) that performs the final write(Q) operation in
schedule S must also perform the final write(Q) operation in
schedule S’.
• As can be seen, view equivalence is also based purely on reads and writes
alone.
View Serializability (Cont.)
• A schedule S is view serializable if it is view equivalent to a serial schedule.
• Every conflict serializable schedule is also view serializable.
• Below is a schedule which is view-serializable but not conflict serializable.

• What serial schedule is above equivalent to?

• Every view serializable schedule that is not conflict serializable has blind
writes.
Test for View Serializability
• The precedence graph test for conflict serializability cannot be used directly to
test for view serializability.
• Extension to test for view serializability has cost exponential in the size of
the precedence graph.
• The problem of checking if a schedule is view serializable falls in the class of
NP-complete problems.
• Thus, existence of an efficient algorithm is extremely unlikely.
• However ,practical algorithms that just check some sufficient conditions for
view serializability can still be used.
Recoverable Schedules
• Recoverable schedule — if a transaction Tj reads a data item previously
written by a transaction Ti , then the commit operation of Ti must appear
before the commit operation of Tj.
• The following schedule is not recoverable if T9 commits immediately after the
read(A) operation.

• If T8 should abort, T9 would have read (and possibly shown to the user) an
inconsistent database state. Hence, database must ensure that schedules are
recoverable.
Cascading Rollbacks
• Cascading rollback – a single transaction failure leads to a
series of transaction rollbacks. Consider the following
schedule where none of the transactions has yet committed
(so the schedule is recoverable)

If T10 fails, T11 and T12 must also be rolled back.

Cascadeless Schedules
• Cascadeless schedules — for each pair of
transactions Ti and Tj such that Tj reads a data item
previously written by Ti, the commit operation of Ti
appears before the read operation of Tj.
• Every cascadeless schedule is also recoverable
Concurrency Control
• A database must provide a mechanism that will ensure that all
possible schedules are both:
• Conflict serializable.
• Recoverable and preferably cascadeless
• A policy in which only one transaction can execute at a time
generates serial schedules, but provides a poor degree of
concurrency
• Concurrency-control schemes tradeoff between the amount of
concurrency they allow and the amount of overhead that they
incur
• Goal – to develop concurrency control protocols that will
assure serializability.
Lock Based Protocol
• 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.
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.
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.
Two-phase locking (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.
Two-phase locking (2PL)
• Growing phase: from step
1-3
• Shrinking phase: from
step 5-7
• Lock point: at 3
Timestamp Ordering Protocol
• The Timestamp Ordering Protocol is used to order the transactions
based on their Timestamps. The order of transaction is nothing but
the ascending order of the transaction creation.
• Let's assume there are two transactions T1 and T2. Suppose the
transaction T1 has entered the system at 007 times and transaction
T2 has entered the system at 009 times. T1 has the higher priority,
so it executes first as it is entered the system first.
Basic Timestamp Ordering Protocol (BTOS)
• 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.
References
• RamezElmasri and Shamkant B. Navathe, “Fundamentals of Database System”, The
Benjamin / Cummings Publishing Co.
• Korth and Silberschatz Abraham, “Database System Concepts”, McGraw Hall.
• C.J.Date, “An Introduction to Database Systems”, Addison Wesley.
• Thomas M. Connolly, Carolyn & E. Begg, “Database Systems: A Practical Approach
to Design, Implementation and Management”, 5/E, University of Paisley, Addison-
Wesley.
• https://15445.courses.cs.cmu.edu/fall2018/slides/18-timestampordering.pdf

40
THANK YOU

For queries
Email: deepinder.e9237@cuimail.in

41