DBMS 4.pdf

UNIT 4
Transactions Management and
Concurrency Control

Contents
• Transactions Management and Concurrency Control: Transaction
concept, transaction states, ACID properties, serializability- Conflict
Serializability, View Serializability, Testing for Serializability, recoverability,
schedules-serial schedules, cascadeless and recoverable schedules.
• Concurrency Control: Concurrency control - lock based protocols, time-
stampbased protocols, deadlock handling.

Transaction concept
➢ Transactions is a set of operations that are used for performing
a logical operation. OR the execution of a program that
accesses or changes the contents of the database is
➢ Ex: Air- Line Reservation System
-Bank Transaction

Read and Write operation
Every database operation ,involves two major operations :
1. read_item(X): read a database item named X into a program
variable
2. write_operation(X): write the value of a program variable X
into the database item named X
Steps involved in read_item operation:
i. Find the address of the disk block that contain the item X
ii. Copy the disk block into a buffer in main memory
iii. Copy item X from the buffer to the program variable X
Steps involved in write_item operation:
i. Find the address of the disk block of X
ii. Copy the disk block into a buffer in main memory
iii. Copy the program variable in to the buffer
iv. Store the updated block from buffer to disk

Transaction concept
• EX: T1 and T2 are transactions having set of instructions.

The ACID Properties:
Atomicity −
➢ This property states that a transaction must be treated as an
atomic unit, that is, either all of its operations are executed or
none.
➢ There must be no state in a database where a transaction is left
partially completed.
➢ States should be defined either before the execution of the
transaction or after the execution/abortion/failure of the
transaction.
➢ It involves the following two operations.
✓ Abort: If a transaction aborts, changes made to database are
not visible.
✓ Commit: If a transaction commits, changes made are visible.
➢ Atomicity is also known as the ‘All or nothing rule’.

Consistency −
➢ The database must remain in a consistent state after any transaction.
➢ No transaction should have any adverse effect on the data residing
in the database.
➢ If the database was in a consistent state before the execution of a
transaction, it must remain consistent after the execution of the
transaction as well.
OR
✓ This means that integrity constraints must be maintained so that
the database is consistent before and after the transaction.
▪ It refers to the correctness of a database.
▪ EX: 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

ISOLATION
▪ In a database system where more than one transaction are
being executed simultaneously and in parallel, the property of
isolation states that “all the transactions will be carried out and
executed as if it is the only transaction in the system”.
▪ No transaction will affect the existence of any other
transaction. OR
✓ Isolation ensures that multiple transactions can occur
concurrently without leading to the inconsistency of database
state.
▪ Transactions occur independently without interference.
▪ 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.
✓ Isolation ensures that the concurrently execution of
transactions will result in a state that is equivalent to a state
achieved these were executed serially in some order.

DURABILITY
➢ The database should be durable enough to hold all its latest
updates even if the system fails or restarts.
➢ If a transaction updates a chunk of data in a database and
commits, then the database will hold the modified data.
➢ If a transaction commits but the system fails before the data
could be written on to the disk, then that data will be updated
once the system brings back into action.
OR
✓ Durability 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 if a system
failure occurs.
▪ These updates now become permanent and are stored in
non-volatile memory.
▪ The effects of the transaction, thus, are never lost.

Transaction States
➢ Every transaction
undergoes several states
in its execution.
➢ A transaction can be in
any one of the following
states:
1. Start
2. Partially Committed
3. Committed
4. Failed
5. Aborted
6. Terminate

Transaction States
• Active: the initial state; the
transaction stays in this state
while it is executing.
• Partially committed, after the
final statement has been
executed.
• Failed, after the discovery that
normal execution can no
longer proceed.
• Aborted, after the transaction
has been rolled back and the
database has been restored to
its state prior to the start of
the transaction.
• Committed, after successful
completion

Transaction States
State diagram Transaction

The database recovery module can select one of the two operations after a
transaction aborts −
1. Re-startthe transaction
2. Kill the transaction

Schedule
Schedule: Is a process of lining the transactions and executing
them one by one. OR
A schedule S is a set of n transactions T1,T2,….Tn with a
particular ordering.
Schedule is a chronological execution sequence of a transaction
is called a schedule. A schedule can have many transactions in
it, each comprising of a number of instructions/tasks
➢ 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.
1. Serial schedule.
2. Non-serial schedule

Serial Schedule
A schedule is called serial schedule,
if the transactions in the schedule
are defined to execute one after the
other.
✓ Serial Schedule − Is a schedule
in which transactions are aligned
in such a way that one
transaction is executed first.
✓ When the first transaction
completes its cycle, then the next
transaction is executed.

Serial Schedule
• Schedules in which the transactions are executed non-interleaved,
i.e., a serial schedule is one in which no transaction starts until a
running transaction has ended are called serial schedules.
• Ex: Consider the schedule involving two transactions T1 and T2.
where R(A) denotes a read operation is performed on some data
item ‘A’.
• This is a serial schedule since the transactions perform serially in the
order T1 →T2
T1 T2
R(A)
W(A)
R(A)
W(A)
T1 T2
R(A)
W(A)
R(A)
W(A)

Non-Serial Schedule:
• In Non serial Scheduling the operations of multiple transactions are
interleaved.
• Unlike the serial schedule where one transaction must wait for another to
complete all its operation, in the non-serial schedule, the other
transaction proceeds without waiting for the previous transaction to
complete.
• This might lead to a rise in the concurrency problem. The transactions
are executed in a non-serial manner, keeping the end result correct and
same as the serial schedule.
• The Non-Serial Schedule can be divided further into
1. Serializable
i) Conflict Serializable
ii) View Serializable
2. Non-Serializable
i) Recoverable --1. Cascading Schedules
2. Cascadless Schedules
3. Strict Schedules
ii) Non Recoverable
T1 T2
R(A)
R(A)
W(A)
W(A)

Non Serial schedule -Serializable / serializability
• Is a schedulehas a propertyof serializable- serializable
• The non-serial schedule is said to be in a serializable schedule only when
it is equivalentto the serial schedules,for an n number of transactions.
• This is used to maintain the consistency of the database.
• It is mainly used in the Non-Serial scheduling to verify whether the
schedulingwill lead to any inconsistency or not.
✓ A serial schedule does not need the serializability, because it follows a
transaction onlywhen the previous transaction is complete.
• A serializable schedule helps in improving both resource utilization and
CPU throughput.
• Two types of Non SerializableSchedule
1. Conflict Serializable
2. View Serializable

Two Types Serializable
i. Conflict Serializable:
A schedule is called conflict serializable if it can be transformed
into a serial schedule by swapping non-conflicting operations.
Two operations are said to be conflicting if all conditions satisfy:
1. They belong to different transactions R(X) and W(X)
2. They operate on the same data item
3. At Least one of them is a write operation
ii. View Serializable:
➢ A Schedule is called view serializable if it is view equal to
a serial schedule (no overlapping transactions).
➢ A conflict schedule is a view serializable but if the
serializability contains blind writes, then the view
serializable does not conflict serializable.

1 .Conflict Serailizability
A schedule is conflict serializable if it is conflict equivalent to
some serial schedule.
- Conflict Equivalent: Two schedules are said to be conflict equivalent when
one can be transformed to another by swapping non-conflictingoperations.
➢ Conflict Serializable: A schedule is called conflict serializable if
it can be transformed into a serial schedule by swapping non-
conflicting operations.
➢ Two operations are said to be conflicting if all conditions
satisfy:
• They belong to different transactions R(X) and W(X)
• They operate on the same data item : - On X item only
• At Least one of them is a write operation: At least one of them is write

Types Of Equivalence Schedule
• Conflict Equivalence:
✓ Two schedules are said to be conflict equivalent when one
can be transformed to another by swapping non-
conflicting operations.
• View Equivalence:
✓ Two schedules are view-equivalent if they produce the
same set of results when executed against the same
database state.

Conflicting operations
Two operations are said to be conflicting if all below conditions are
satisfied:
➢ They belong to different transaction
➢ They operate on same data item
➢ At Least one of them is a write operation
➢ R(A), R(A) → non conflict operations
R(A), W(A) → conflict operations
W(A), R(A) → conflict operations
W(A),W(A) → conflict operations
• R(B), R(A) → non conflict operations
R(B), W(A) → non conflict operations
W(B), R(A) → non conflict operations
W(A),W(B) → non conflict operations

2 .View Serializable:
➢ A Schedule is called view serializable if it is view
equal to a serial schedule (no overlapping
transactions).
➢ A conflict schedule is a view serializable but if the
serializability contains blind writes, then the view
serializable does not conflict serializable.

2. Non-Serializable
The non-serializable schedule is divided into two types:
1. Recoverable
2. Non recoverable Schedule.
i. Recoverable Schedule
if in a schedule, 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 called as a
Recoverable Schedule.

Types of Recoverable Schedules-
• A recoverable schedule may be any one of these kinds-
1. Cascading Schedule
2. Cascadeless Schedule
3. Strict Schedule

Recoverable Schedule
➢ Schedules in which
transactions commit only
after all transactions whose
changes they read commit
are called recoverable
schedules.
➢ if some transaction Tj is
reading value updated or
written by some other
transaction Ti, then the
commit of Tj must occur
after the commit of Ti.
➢ Example – Consider the following schedule involving two
transactions T1 and T2.
➢ This is a recoverable schedule since T1 commits before T2,
that makes the value read by T2 correct.

Non-Recoverable Schedule:
Example:
➢ Consider the following schedule involving two transactions.
T1 and T2
➢ T2 read the value of A written by T1, and committed.
➢ T1 later aborted, therefore the value read by T2 is wrong, but
since T2 committed,this schedule is non-recoverable
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.

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.
➢ It simply leads to the wastage of CPU time.
➢ Transaction T2 dependson transactionT1.
➢ The failure of transaction T1 causes the transactionT2 to rollback.
➢ The rollbackof transactionT2 causes the transaction T3 to rollback.
➢ The rollback of transaction T3 causes the transaction T4 to rollback.
Such a rollbackis called as a CascadingRollback.

Cascading Schedule
Here,
Transaction T2 depends on transaction T1.
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.
If the transactions T2, T3 and T4 would
have committed before the failure of
transaction T1, then the schedule would
have been irrecoverable.

Cascade less 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.
• In other words, Cascade
less schedule allows
only committed read
operations.
• Therefore, it avoids
cascading roll back and
thus saves CPU time.
In other words, Cascade less schedule
allows only committed read operations.

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, - called as a Strict
Schedule.
• In other words, Strict schedule allows
only committed read and write
operations.
• Clearly, strict schedule implements more
restrictions than cascade less schedule.
Note
➢Strict schedules are more strict than
cascade less schedules.
➢All strict schedules are cascade less
schedules.
➢All cascade less schedules are not strict
schedules.

What is concurrency control in DBMS?
What is Concurrency?
➢ Concurrency means executing multiple transactions at a
time. It is required increase time efficiency.
➢ Concurrency control concept
o It comes under the transaction in DBMS.
o It is a procedure which helps for the management of two
simultaneous processes to execute without conflicts between
each other, these conflicts occur in multi user systems.
o Concurrency control required to maintain consistency of data.
✓ It means , if many transactions try to access the same data,
then inconsistency arises.
✓ EX: If we take ATM machines and do not use concurrency,
multiple persons cannot draw money at a time in different
places. This is where we need concurrency.

Advantages
• The advantages of concurrency control :
1. Waiting time will be decreased.
2. Response time will decrease.
3. Resource utilization will increase.
4. System performance & Efficiency is increased.

Control concurrency
• The simultaneous execution of transactions over shared
databases can create several data integrity and consistency
problems.
• For example,
✓ If too many people are logging in the ATM machines. Serial
updates and synchronization in the bank servers should
happen whenever the transaction is done. If not it, gives
wrong information and wrong data in the database.
• Main problems in using Concurrency
1. Updates will be lost −
2. Uncommitted Dependency or dirty read problem −
3. Inconsistent retrievals −
•

Main problems in using Concurrency
1. Updates will be lost −
✓ One transaction does some changes and another transaction deletes that
change.
✓ That is , One transaction nullifies the updatesof anothertransaction.
2. Uncommitted Dependency or dirty read problem −
✓ One variable has updated in one transaction, at the same time
another transaction has started and deleted the value of the
variable, there the variable is not getting updated or committed
that has been done on the first transaction.
✓ This gives us false values or the previous values of the variables.
This is a major problem.
3. Inconsistent retrievals −
One transaction is updating multiple different variables, another
transaction is in a process to update those variables, and the
problem occurs is inconsistency of the same variable in different
instances.

CONCURRENCY CONTROL
• Introduction :
• One of the fundamental properties of a transaction is isolation.
-Isolation ensures that multiple transactions can occur
concurrently without leading to the inconsistency of
database state.
• When several transactions execute concurrently in the
database, however, the isolation property may no longer be
preserved.
• To ensure that it is, the system must control the interaction
among the concurrent transactions; this control is achieved
through a mechanisms called concurrency-control schemes.
• In this chapter, we will see the management of concurrently
executing transactions, and we ignore failures.
• In next we shall see how the system can recover from
failures.

ISOLATION
➢ In a database system where more than one transaction are
being executed simultaneously and in parallel, the property of
isolation states that all the transactions will be carried out
and executed as if it is the only transaction in the system.
➢ No transaction will affect the existence of any other
transaction.
✓ Isolation ensures that multiple transactions can occur concurrently
without leading to the inconsistency of database state.
▪ Transactions occur independently without interference.
▪ 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.
✓ Isolation ensures that the concurrently execution of transactions will
result in a state that is equivalent to a state achieved these were
executed serially in some order.
OR

Lock-Based Protocols
• One way to ensure isolation is to require that data items be
accessed in a mutually exclusive manner; that is, while one
transaction is accessing a data item, no other transaction can
modify that data item.
• The most common method used to implement this requirement
is to allow a transaction to access a data item only if it is
currently holding a lock on that item.

Lock
➢ A lock is a variable associated with a data item that describes
a status of data item with respect to possible operation that can
be applied to it.
➢ i.e. lock is a variable that denotes those operations that can
be executed on the particular data item
➢ So Lock is a mechanism in which a transaction cannot read or
write data unless the appropriate lock is acquired.
✓ This helps in eliminating the concurrency problem by
locking a particular transaction to a particular user.
✓ They synchronize the access by concurrent transactions to
the database items.
✓ It is required in this protocol that all the data items must be
accessed in a mutually exclusive manner.

Locks..
➢ A lock is a mechanism to control concurrent access to a data
item
➢ Data items can be locked in two modes :
1. Exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2. Shared (S) mode. Data item can only be read.
S-lock is requested using lock-S instruction.
➢ Lock requests are made to concurrency-control manager.
Transaction can proceed only after request is granted.
➢ A transaction implementing, lock based concurrency control
cannot read or write a statement until it has obtained the
required locks.

Lock
• Shared Lock (S): also known as Read-only lock.
✓ As the name suggests it can be shared between transactions,
because while holding this lock the transaction does not have
the permission to update data on the data item.
✓ S-lock is requested using lock-S instruction.
• Exclusive Lock (X):
• Data item can be both read as well as written.
• This is Exclusive and cannot be held simultaneously on the same
data item. X-lock is requested using lock-X instruction.
• EX: T1 T2
S(A) X(A)
R(A) R(A)
U(A) W(A)
U(A)

Lock Based Protocols
• A transaction may be granted a lock on an item if the
requested lock is suitable to be used together
(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 transactionmay hold any lock on the item.
• Ex: Let A and B are arbitrary lock modes. Suppose a transaction
Ti requests a lock of mode A on item Q on which transaction Tj
(Ti ≠ Tj ) currently holds a lock of mode B.
• If transaction Ti can be granted a lock on Q immediately, in spite
of the presence of the mode B lock, then we say mode A is
compatible with mode B. Such a function can be represented
conveniently by a matrix.
• If a lock is not granted, the requesting transaction is made
to wait till all incompatible locks held by other transactions
have been released. Then the lock is granted.

T1 T2
LOCK_S(A)
R(A)
UNLOCK_S(A)
LOCK_X(A)
R(A)
W(A)
UNLOCK_X(A)
T1 T2
LOCK_S(A)
R(A)
UNLOCK_X(A)
LOCK_S(A)
R(A)
UNLOCK_S(A)
LOCK_X(B)
R(B)
W(B)
UNLOCK_X(B)

Disadvantages of shared –exclusive Lock Protocol
1.May or may not serializability
2.Irrecoverability
3.Deadlock Problem
4.Stravation
GRANT
REQUEST

1.May or may not serializability
T1 T2
X(A)
R(A)
W(A)
U(A) S(A)
R(A)
U(A)
X(B)
R(B)
W(B)
U(B)
T1→T2→T1 NON SERIALISABLE
WE HAVE TO CHANGE IT TO
T1→ T2 OR T2→T1

Irrecoverability
T1 T2
X(A)
R(A)
.W(A) S(A )
R(A)
U(A)
. -----
. -----
. -----
. commit
fail
Rollback
,so it is not possible to recover the
Transaction T2, a it is committed and its
value is stored in the database , but
inconsistence. - so it is called
irrecoverable
S(A) - Lock is Not granted , Make it wait until it
is released by T1. But after some time when T1
releases its lock then S(A) lock granted to
transaction T2 , and T2 performs its operation
like R(A) and Committed .
But T2 demand for lock on read for item A -R(A) ,
before T1 release the X(A)
Assume If Transaction T1, in future fails , it is
to be roll backed , then T2 also rollback , because
it read the vale of A which is written by
Transaction T1(i.e. W(A) .
T1 demands for exclusive read on item A i.e.
W(A) . Granted immediately as it is free.

NOT FREE FROM DEADLOCK
T1 T2
X(A) Granted
X(B) Granted
WAIT X(B)
X(A) Wait
T1 is waiting X(B) – which held by T2.
T2 is waiting X(A) –WHICH IS HELD BY T1

Granting of Locks
• When a transaction requests a lock on a data item in a particular mode, and no
other transaction has a lock on the same data item in a conflicting mode, the
lock can be granted.
• However, care must be taken to avoidthe followingscenario.
T2 has a shared-mode lock on a data item, and T1
requests an exclusive-mode lock on the data item. T1 has
to wait for T2 to release the shared mode lock.
Meanwhile, a T3 may request a shared-mode lock on
the same data item.
The lock request is compatible with the lock granted to
T2, so T3 may be granted the shared-mode lock.
At this point T2 may release the lock, but still T1 has to
wait for T3 to finish.
But again, there may be a new transaction T4 that
requests a shared-mode lock on the same data item, and
is granted the lock before T3 releases it.
Each requests a shared mode lock on the data item, and
each transaction releases the lock a short while after it is s
granted, but T1 never gets the exclusive-mode lock on the
data item. The transaction T1 may never make progress,
and is said to be starved.
T1 T2 T3 T4
LOCK_S(A)
LOCK_X
(A)
LOCK_S(A
)
UNLOCK_
S(A)
LOCK_S(A)
UNLOCK_
S(A)
UNLOCK_S
(A)

STARVATION
T1 T2 T3 T4
LOCK_S(A)
LOCK_X(A)
LOCK_S(A)
UNLOCK_S(A) LOCK_S(A)
UNLOCK_S(A)
UNLOCK_S(A)

To avoid starvation Granting of Locks
• To avoid starvation of transactions by granting locks in the
following manner:
• When a transaction Ti requests a lock on a data item Q in a
particular mode M, say S(A) the concurrency-control manager
grants the lock provided that:
1. There is no other transaction holding a lock on Q in a
mode that conflicts with M.
2. There is no other transaction that is waiting for a lock on Q
and that made its lock request before Ti . Thus, a lock
request will never get blocked by a lock request that is
made later. Compatible table

• Upgrade: A 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.

T1 T2
LOCK_X(A)
LOCK_X(B)
LOCK_X(B)
LOCK_X(A)
T1 T2 T3 T4
LOCK_S(A)
LOCK_X(A)
LOCK_S(A)
UNLOCK_S(A) LOCK_S(A)
UNLOCK_S(A)
UNLOCK_S(A)

Different locking protocols
1. Simplistic Lock Protocol
2. Two-Phase Locking Protocol
3. Strict Two-Phase Locking Protocol
4. Rigorous two-phase locking protocol

i) Simplistic Lock Protocol
➢ A lock is obtained by the
transaction on the data
value before the write
operation is performed.
➢ After the write
operation, the lock can be
released.
➢ An example of Simplistic
Lock Protocol is:
➢There are two transactions T1 and T2 shown above.
➢There are no locks required for the read operation but before
the write operation, each of these transactions acquires a lock
and releases it after.

Simplistic Lock Protocol
➢There are two transactions T1 and T2 shown above.
➢There are no locks required for the read operation but before
the write operation, each of these transactions acquires a lock
and releases it after.

ii) Two-phase locking protocol
• Is a extension to the Shared –Exclusive protocol.
• Here we are using two phases :
• One protocol that ensures serializability is the two-phase
locking protocol.
• This protocol requires that each transaction issue lock and
unlock requests in two phases:
1. Growing phase. A transaction may obtain locks, but may
not release any lock.
2. Shrinking phase. A transaction may release locks, but may
not obtain any new locks.

2. Two Phase Locking Protocol
• A transaction is said to
follow the Two-Phase
Locking protocol if
Locking and Unlocking
can be done in two
phases.
• Growing Phase: New locks
on data items may be acquired
but nonecan be released.
• Shrinking Phase: Existing
locks may be released but no
new locks can be acquired.
T1 T2
LOCK_S(A)
LOCK_S(A)
LOCK_X(B)
UNLOCK_S(A)
LOCK_X(D)
UNLOCK_X(B)
UNLOCK_S(A)
UNLOCK_S(D)

The Two-Phase Locking Protocol
• A protocol which ensures conflict-
serialisable schedules.
• Phase 1: Growing Phase
– Transaction may obtain locks
– Transaction may not release locks
• Phase 2: Shrinking Phase
– Transaction may release locks
– Transaction may not obtain locks
• The protocol assures serializability.
• It can be proved that the transactionscan be
serialized in the order of their lock points
(i.e., the point where a transaction acquired
its final lock).
Time
Locks
• Initially, a transaction is in the growing phase. The transaction
acquires locks as needed.
• Once the transaction releases a lock, it enters the shrinking phase,
and it can issue no more lock requests.

ii) Two-Phase Locking Protocol
• The two-phase locking
protocol has two phases -
growing and shrinking
phase.
• The transaction can only
acquire locks when it is in
the growing phase.
• When it enters the shrinking
phase, it can release the
previously acquired locks
but cannot acquire new
locks.
• The exclusive locks are
represented by X and the
shared locks are represented
by S.
In the above example, T1 and T2 share
the variable A using a shared lock as
only read operation is performed onA.
T1 acquires an exclusive lock on B for
the write operation and releases it soon .
T2 does the same with C.

Disadvantages
1. May or May not recoverability
2. Deadlock
3. Starvation
4. Rollback
1. May or May not recoverability
T1 T2
X(A)
R(A) S(A) NOT GRANTED
W(A) R(A)
U(A) -----
. -----
. W(A)
.. COMMIT
FAILED T2 IS ALSO ROLLBACK , BUT IT IS NOT
IN FUTURE POSSIBLE AS T2 IS COMMITED
ROLLBACK

2PL NOT FREE FROM cascading roll
T1 T2 T3 T4
LOCK_X(A)
R(A)
W(A)
UNLOCK_X(A)
LOCK_S(A)
R(A)
LOCK_S(A)
R(A)
LOCK_S(A)
R(A)

NOT FREE FROM DEADLOC K
T1 T2
X(A) Granted
X(B) Granted
WAIT X(B)
X(A) Wait

STARVATION
T1 T2 T3 T4
S(A)
wait(A) .
.
. S(A)
U(A) .
.
. S(A)
U(A)
.
.
.
U(A) THIS POINT T1 WILL GET X(A)

iii) Strict Two-Phase Locking Protocol
➢ Strict two phase locking protocol is similar to two phase
locking protocol.
➢ The only difference is that in strict 2PL protocol all the
exclusive locks acquired by the protocol need to be held
until the protocol either commits or aborts.

iii) Strict Two-Phase Locking Protocol contd..
➢ In the above example, T1
and T2 share the variable
A using a shared lock as
only read operation is
performed on A.
➢ T1 acquires an exclusive
lock on B for the write
operation and T2 does
the same with C.
➢ The exclusive locks are
released only after the
transactions have
committed. However,
there is no such bound
for the shared locks.

S2PL CASCADLESS ROLLBACK
EX: CASCAD ROLLBACK
T1 T2 T3
X(A)
R(A)
.W(A) S(A)
. R(A) S(A)
. R(A)
U—
.
.
. Rollback
FAILED Rollback
Rollback
▪ T2 Read this value written by T1 but which
is inconsistence as if T1 goes failed instead
of unlock , then T1 has to be roll back.
▪ As of this T2 also roll back and T3 also roll
back
▪ This leads to a cascade rollback
▪ SOLUTION
Solution
T1 T2
X(A)
R(A)
W(A) S(A)
.. R(A)
.
.
COMMIT
U(A
➢ T1 has to commit before read the value
of A by T2.
➢ With this T2 now read the value of A
from database which is committed , and
saved in the database.

iii)Strict 2-PHASE LOCK
➢ This requires that in addition
to the lock being 2-Phase all
Exclusive(X) locks held by
the transaction be released
until after the Transaction
Commits.
➢ Following Strict 2-PL
ensures that our schedule is:
1. Recoverable
2. Cascade less
T1 T2
LOCK_X(A)
R(A)
W(A)
LOCK_S(A)
R(A)
COMMIT
UNLOCK_X(
A)

• Centralized 2PL : Single site handles all locks
o In Centralized 2 PL, a single site is responsible for lock management
process.
o It has only one lock manager for the entire DBMS.
• Primary copy 2PL: Each data item is assigned A primary site to handle its locks.
Data is not replicated.
o Many lock managers are distributed to different sites.
o After that, a particular lock manager is responsible for managing the
lock for a set of data items.
o When the primary copy has been updated, the change is propagatedto
the slaves
• Distributed 2PL : Assumes data can be replicated
o In this kind of two-phase locking mechanism, Lock managers are
distributed to all sites.
o They are responsible for managing locks for data at that site. If no data
is replicated, it is equivalent to primary copy 2PL. Communication costs
of Distributed 2PL are quite higher than primary copy 2PL

iv) Rigorous two-phase locking protocol
• Rigorous two phase locking protocol is merely an
extension of two phase locking protocol and strict two
phase locking protocol.
• Here, all the locks held by a transaction, whether shared or
exclusive, are only released once the transaction commits
or aborts.

iv) Rigorous two-phase locking protocol
➢ In the above example, T1 and T2 share the variable A using a shared lock as only
read operation is performed on A.
➢ T1 acquires an exclusive lock on B for the write operation and T2 does the same
with C.
➢ Both the shared locks and the exclusive locks are only released after the transactions
have committed.

Rigorous 2-PHASE LOCK
• This requires that in addition to the lock being 2-Phase all
Exclusive(X) and Shared(S) locks held by the transaction be
released until after the Transaction Commits.
• Following Rigorous 2-PL ensures that our schedule is:
1. Recoverable
2. Cascade less
• Hence, it gives freedom from Cascading Abort which was
still there in Basic 2-PL and moreover guarantee Strict
Schedules but still, Deadlocks are possible!

Rigorous 2-PL
T1 T2
LOCK_S(A)
R(A)
LOCK_S(A)
R(A)
COMMIT
UNLOCK_SA)

Conservative 2PL
• Conservative two-phase locking (C2PL) is a locking method used in
DBMS and RDBMS databases. -prevents deadlocks.
• The difference between 2PL and C2PL is that , C2PL's transactions
obtain all the locks they need before the transactions begin.
• This protocol requires the transaction to lock all the items it
access before the transaction begins execution by pre-declaring
its read-set and write-set.
• If any of the pre-declared items needed cannot be locked,
the transaction does not lock any of the items, instead, it
waits until all the items are available for locking.
• Schedule following this will not have a Growing Phase as
we’ve in Basic, Strict, and Rigorous 2-PL.
• We only have to lock all the items beforehand, so releasing
or unlocking them has no restrictions as we had in Strict or
Rigorous 2-PL.

Disadvantage :
• In C2PL , each transaction needs to declare its read and
write set , which is not always possible.
Because of these limitations, C2PL is not used very
frequently.
• Although we get a Deadlock free schedule in this protocol, we
may still face drawbacks like Cascading Rollbacks.
So this protocol does not ensure Strict Schedules.
• This is a disadvantage in comparison to Strict and Rigorous 2-
PL.

Example
Lock-X(A)
Lock-X(B)
Read(A)
Read(B)
Write(A)
Unlock(A)
Commit
Unlock(B)

2. 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.
• The priority of the older transaction is higher that's why it executes
first.
• To determine the timestamp of the transaction, this protocol uses
system time or logical counter.
• The lock-based protocol is used to manage the order between conflicting
pairs among transactionsat the execution time.
• But Timestamp based protocols start working as soon as a transaction is
created.
• 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.
• The timestamp ordering protocol also maintains the timestamp of last 'read'
and 'write' operation on a data.

Time Stamping
• Time stamp is a unique identifier created by DBMS that
indicates relative starting time of a transaction.
• Whatever transaction we are doing it stores the starting time
of the transaction and denotes a specific time.
• This can be generated using a system clock or logical counter.
• This can be started whenever a transaction is started.
• Here, the logical counter is incremented after a new timestamp
has been assigned.

i) BasicTimestamporderingprotocol works as Rules
1. Check the followingcondition
whenever a transactionTi issues a Read (X) operation:
a) If W_TS(A) >TS(Ti) then the operation is rejected -roll back
b) Otherwise execute R(A) operation.
set RTS(A) =Max{RTS(A), TS(Ti)
2. Check the followingcondition
whenever a transactionTi issues a Write(X) operation:
a) If RTS(A) > TS(Ti) then the operationis rejected, rollback
b) If WTS(A)> < TS(Ti) then the operation is rejected and Ti is rolled back
otherwise the operation WRITE(A) is executed.
Set WTS (A) = TS(Ti)
Where,
• TS(TI) denotes the timestampof the transaction Ti.
• R_TS(X) denotes the Read time-stampof data-item X.
• W_TS(X) denotes the Write time-stampof data-item X.

Advantages and Disadvantages of Time Ordering protocol:
• To protocol ensures serializability since the precedence graph
is as follows:
• TS protocol ensures freedom from deadlock that means no
transaction ever waits.
➢ DISADVANTAGE: But the schedule may not be
recoverable and may not even be cascade- free.

TIME STAMP ORDERING PROTOCOL
A B C
RTS 0
100
0
200
0
100
WTS 0 0 0
100
1.Check the following condition
whenever a transaction Ti issues a Read (X)
operation:
a) If W_TS(A) >TS(Ti) then the operation is
rejected -roll back
b) Otherwise execute R(A) operation.
set RTS(A) =Max{RTS(A), TS(Ti)
2. Check the following condition
whenever a transaction Ti issues a Write(X)
operation:
a) If RTS(A) > TS(Ti) then the operation is
rejected, rollback
b) If WTS(A)> < TS(Ti) then the operation is
rejected and Ti is rolled back otherwise the
operation W(A) is executed.
Set WTS (A) = TS(Ti)
T1 T2 T3
R(A)
R(B)
W(C)
R(B)
W(B)
W(A)
Example:
T1: RTS(A) 0>100 FALASE THEN --RTS(A) =100:
T2: RTS(B) 0> 200 THEN RTS(B)=200
T1: RTS(C) 0>100 FALSE THEN RTS(C) = 100
T3:WTS(B) 0>300 FALSE THEN

Validation Based Protocol/ optimisticconcurrency
• Validation phase is also known as optimistic concurrency
control technique.
• In the validation based protocol, the transaction is executed in
the following three phases:
1. Read phase: In this phase, the transaction T is read and
executed. It is used to read the value of various data items and
stores them in temporary local variables.
It can perform all the write operations on temporary
variables without an update to the actual database.
2. Validation phase: In this phase, the temporary variable value
will be validated against the actual data to see if it violates the
serializability.
3. Write phase: If the validation of the transaction is validated,
then the temporary results are written to the database or system
otherwise the transaction is rolled back.

Validation Based Protocol
➢ Here each phase has the following different timestamps:
i. Start(Ti): It contains the time when Ti started its execution.
ii. Validation (Ti): It contains the time when Ti finishes its read
phase and starts its validation phase.
iii. Finish(Ti): It contains the time when Ti finishes its write
phase.
➢ This protocol is used to determine the time stamp for the
transaction for serialization using the time stamp of the validation
phase, as it is the actual phase which determines if the transaction
will commit or rollback.
Hence TS(T) = validation(T).
➢ The serializability is determined during the validation process. It
can't be decided in advance.
➢ While executing the transaction, it ensures a greater degree of
concurrency and also less number of conflicts.
➢ Thus it contains transactions which have less number of rollbacks.

Deadlock in DBMS
➢ A deadlock is a condition where two or more transactions are
waiting indefinitely for one another to give up locks.
➢ Deadlock - no task ever gets finished and is in waiting state forever.
➢ For example: In the student table, transaction T1 holds a lock on
some rows and needs to update some rows in the grade table.
Simultaneously, transaction T2 holds locks on some rows in
the grade table and needs to update the rows in the
Student table held by Transaction T1.
➢ Now, the main problem arises. Now Transaction T1 is waiting for
T2 to release its lock and similarly, transaction T2 is waiting for T1
to release its lock.
THUS , All activities come to a halt state and remain at a
standstill.
It will remain in a standstill until the DBMS detects the
deadlock and aborts one of the transactions.

Deadlock Avoidance
• When a database is stuck in a deadlock state, then it is better to
avoid the database rather than aborting or restating the
database.
• This is a waste of time and resource.
• Deadlock avoidance mechanism is used to detect any
deadlock situation in advance.
1. A method like "wait for graph" is used for detecting the
deadlock situation but this method is suitable only for the
smaller database.
2. For the larger database, deadlock prevention method can
be used.
3. USE deadlock detectionand handlingtech:
Allow dead lock to happen
Detect the state
Attempt to recovery protocol

Deadlock Detection
• In a database, when a transaction waits indefinitely to obtain a
lock, then the DBMS should detect whether the transaction is
involved in a deadlock or not.
• The lock manager maintains a Wait for the graph to detect the
deadlock cycle in the database.

Wait for Graph
• This is the suitable method for deadlock detection.
• In this method, a graph is created based on the transaction and
their lock.
• If the created graph has a cycle or closed loop, then there is a
deadlock.
• The wait for the graph is maintained by the system for
every transaction which is waiting for some data held by
the others.
• The system keeps checking the graph if there is any cycle
in the graph.

Deadlock Prevention
• Deadlock prevention method is suitable for a large database.
• If the resources are allocated in such a way that deadlock never
occurs, then the deadlock can be prevented.
• The DBMS system analyzes the operations of the
transaction whether they can create a deadlock situation or
not.
• If they do, then the DBMS never allowed that transaction to
be executed.

Wait-Die scheme (non preemption
• In this scheme, if a transaction requests for a resource which is already
held with a conflicting lock by another transaction then the DBMS simply
checks the timestampof both transactions.
It allows the older transaction to wait until the resource is available
for execution.
• Let's assumethere are two transactions Ti and Tj and
• let TS(T) is a timestampof any transaction T.
• If T2 holds a lock by some other transaction and
• T1 is requesting for resources held by T2 then the following actions are
performed by DBMS:
• Check if TS(Ti) < TS(Tj) - If Ti is the older transaction and Tj has held some
resource, then Ti is allowed to wait until the data-item is available for
execution.
That means if the older transaction is waiting for a resource which is locked
by the younger transaction, then the older transaction is allowed to wait for
resource until it is available.
• Check if TS(Ti) < TS(Tj) - If Ti is older transaction and has held some resource
and if Tj is waiting for it, then Tj is killed and restarted later with the random
delay but with the same timestamp.

Wound wait (pre-emptive) scheme
• In wound wait scheme, if the older transaction requests for a
resource which is held by the younger transaction, then older
transaction forces younger one to kill the transaction and
release the resource.
• After the minute delay, the younger transaction is restarted but
with the same timestamp.
• If the older transaction has held a resource which is requested
by the Younger transaction, then the younger transaction is
asked to wait until older releases it.

Recovery from deadlock
• Selection of victim
Time
How many data items held by T
How many more data items T is required
How many transaction will be involved in the roll back
Rollback
1. partial rollback
2. total rollback
Starvation

• Time Stamp ordering protocol (Refer Notes)
• Deadlock Handling (Refer Notes)
• NOTE: Refer notes for serailizability problems

DBMS 4.pdf

More Related Content

What's hot (20)

Similar to DBMS 4.pdf (20)

Recently uploaded (20)

DBMS 4.pdf