0% found this document useful (0 votes)
11 views32 pages

2PL Protocol

dbms
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views32 pages

2PL Protocol

dbms
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

PPT for Session No.

: 4th, 5th and 6th of Unit-V


Prepared by: Dr. Pragnyaban Mishra
Professor-CSE, GITAM-Visakhapatnam

Course Code: CSEN2061


Course Name: DATABASE MANAGEMENT SYSTEMS
Branch: CSE, 3rd Yr
Semester: Even (2024-25)
Session No: 4th / Unit-V
Session Topic: Concurrency control schemes in DBMS: Lock based

Session No: 5th / Unit-V


Session Topic: Explanation about 2PL, Strict 2PL
Some of the main techniques used to control concurrent execution of transactions
are based on the concept of locking data items.
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. Generally, 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.
Binary Locks. A binary lock can have two states or values: locked and unlocked
(or 1 and 0, for simplicity). A distinct lock is associated with each database item X.
If the value of the lock on X is 1, item X cannot be accessed by a database operation
that requests the item. If the value of the lock on X is 0, the item can be accessed
when requested, and the lock value is changed to 1. We refer to the current value
(or state) of the lock associated with item X as lock(X).
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. If LOCK(X) =
1, the transaction is forced to wait. If LOCK(X) = 0, it is set to 1 (the
transaction locks the item) and the transaction is allowed to access item X. When
the transaction is through 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. Hence, a binary lock enforces mutual exclusion on the data
item.
Conservative, Strict, and Rigorous Two-Phase Locking. There are a number of variations
of two-phase locking (2PL). The technique just described is known as basic 2PL.

A variation known as conservative 2PL (or static 2PL)


requires a transaction to lock all the items it accesses before the transaction begins execution,
by predeclaring its read-set and write-set. the read-set of a transaction is the set of all items
that the transaction reads, and the write-set is the set of all items that it writes. If any of the
predeclared items needed cannot be locked, the transaction does not lock any item; instead, it
waits until all the items are available for locking. Conservative 2PL is a deadlock-free
protocol.
A transaction is said to follow the two-phase
locking protocol if all locking operations
(read_lock, write_lock) precede the first unlock
operation in the transaction. Such a transaction
can be divided into two phases: an expanding Example of 2PL Protocol
or growing (first) phase, during which new
locks on items can be acquired but none can be
released; and a shrinking (second) phase,
during which existing locks can be released but
no new locks can be acquired. If lock
conversion is allowed, then upgrading of locks
(from read-locked to write-locked) must be
done during the expanding phase, and
downgrading of locks (from write-locked to
read-locked) must be done in the shrinking
phase
Session No: 6th / Unit-V
Session Topic: Introduction to Serializability: View Serializability;
Conflict Serializability; Recoverability
Formally, a schedule S is serial if, for every transaction T participating in the
schedule, all the operations of T are executed consecutively in the schedule; otherwise,
the schedule is called nonserial. Therefore, in a serial schedule, only one transaction
at a time is active—the commit (or abort) of the active transaction initiates execution
of the next transaction. No interleaving occurs in a serial schedule. One reasonable
assumption we can make, if we consider the transactions to be independent, is that
every serial schedule is considered correct.
(a) Serial schedule A: T1 followed by
T2. (b) Serial schedule B: T2 followed by T1. (c) Two nonserial
schedules C and D with interleaving of operations.
A schedule (or history) S of n transactions T1, T2, … , Tn
is an ordering of the operations of the transactions.
Operations from different transactions can be interleaved
in the schedule S.

Sa: r1(X); w1(X); r1(Y); w1(Y); r2(X); w2(Y) Sb: r2(X); w2(Y); r1(X); w1(X); r1(Y); w1(Y)
Conflicting Operations in a Schedule:-

Two operations in a schedule are said to conflict if they satisfy all three of the following
conditions:
• They belong to different transactions
• They access the same item X
• At least one of the operations is a write_item(X).

Type of Conflicts:-
read-write conflict, write-write conflict
A schedule S of n transactions
is serializable if it is equivalent to some serial schedule of the same n
transactions.

Conflict Equivalence of Two Schedules. Two schedules are said to be


conflict equivalent if the relative order of any two conflicting operations is
the same in both
schedules.
Check Conflict Serializable using Precedency Graph
A schedule S is said to be view serializable if it is view equivalent to
a serial schedule.
Session No: 6th / Unit-V
Session Topic: Recoverability
A schedule where a committed transaction may have to be rolled back during
recovery is called nonrecoverable and hence should not be permitted by the
DBMS. The condition for a recoverable schedule is as follows:

• A schedule S is recoverable if no transaction T in S commits until all


transactions T′ that have written some item X that T reads have committed.

• A transaction T reads from transaction T′ in a schedule S if some item X is


first written by T′ and later read by T. In addition, T′ should not have been
aborted before T reads item X, and there should be no transactions that write
X after T′ writes it and before T reads it (unless those transactions, if any, have
aborted before T reads X).
Log based Recovery in DBMS
Log and log records

1.Transaction identifier: Unique Identifier of the transaction that performed the


write operation.
2.Data item: Unique identifier of the data item written.
3.Old value: Value of data item prior to write.
4.New value: Value of data item after write operation.

Other types of log records are:


1.<Ti start>: It contains information about when a transaction Ti starts.
2.<Ti commit>: It contains information about when a transaction Ti commits.
3.<Ti abort>: It contains information about when a transaction Ti aborts.
Undo and Redo Operations
Because all database modifications must be preceded by the creation of a log
record, the system has available both the old value prior to the modification of the
data item and new value that is to be written for data item. This allows system to
perform redo and undo operations as appropriate:

1.Undo: using a log record sets the data item specified in log record to old value.

2.Redo: using a log record sets the data item specified in log record to new value.
Types of Recovery Techniques in DBMS

•Rollback/Undo Recovery Technique


•Commit/Redo Recovery Technique
•CheckPoint Recovery Technique
Transaction rollback
Recovery by Check Point

The transactions T3 and T5 are in the UNDO queue.


(checked either commit statement is executed prior to
the failure or not
The transactions T2 and T4 are in the REDO queue.
T1 is completed before check point so free from undo
and redo operation.

You might also like