0% found this document useful (0 votes)
9 views11 pages

Unit IV Notes

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)
9 views11 pages

Unit IV Notes

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/ 11

Types of schedules:

Schedule can be classified into mainly two types,


Serial schedule:
If the schedule runs only one transaction at a time and can start other transaction after
computing the first than it is called serial schedule.
Non-serial/concurrent schedule:
A schedule is said to be non-serial schedule if we start executing other transactions before
computing the first one. A schedule in which sequence of instructions of transactions appear
in the same order as they appear in individual transactions but the instructions may be
interleaved with the instructions of different transactions i.e. concurrent execution of
transaction takes place.

Concurrency Control

Advantages of concurrency:
1. Serve many users and provides better throughput by sharing resources.
2. Reduced waiting time response time or turnaround time.
3. Increased throughput or resource utilization

Concurrency control is needed to handle the issues that arise when transactions execute
concurrently. They are the following.

A. Lost Update(write-write problem): An update to an item by a transaction is


overridden by another interleaved transaction without the knowledge of initial update.

Example:
TA TB
Read(I)
I:=I+50

Read(I)
I:=I+100

Write(I)

Write(I)

Transaction A’s update is lost

B. Uncommitted Dependency (Dirty read problem): A transaction reads an item


updated by another transaction that later fails.
Example:
TA TB
Read(I)
I:=I+50
Write(I)
Read(I)
I:=I+100
Write(I)

ROLLBACK

Transaction B reads an uncommitted value of I.

C. Inconsistent Analysis: A transaction calculating an aggregate function uses some,


but not all the updated items of another transaction.
Example:

TA TB
Read(Acc1)
SUM:=Acc1
Read(Acc2)
SUM+:=Acc2
Read(Acc1)
Acc1+:=10
COMMIT

Read(Acc3)
SUM+=Acc3
//SUM value is less by 10 because the
incremented value of Acc1 by TB was
not considered
The value of SUM is inconsistent.
D: Unrepeatable Read (Phantom read problem): When a transaction cannot repeat the
read instructions because the variable is deleted by some other transaction then this
problem is called phantom read problem. In this problem at different instances of time a
transaction read gives different values it is because data item might have been updated by
another transaction.
Example:

TA TB
Read(I)

Delete(I)

Read(I)
DBMS has inbuilt software called scheduler, which determines the correct order of
execution. The scheduler establishes the order in which the operations within concurrent
transactions are executed. The scheduler interleaves the execution of database operations to
ensure serialisability. The scheduler bases its actions on concurrency control algorithms, such
as locking or time stamping methods. The schedulers ensure the efficient utilization of
central processing unit (CPU) of computer system.
It can be observed that the schedule does not contain an ABORT or COMMIT action for
either transaction. Schedules which contain either an ABORT or COMMIT action for each
transaction whose actions are listed in it are called a complete schedule.

Serializability

A given set of interleaved transactions are said to be serializable if and only if it produces the
same results as a serial execution of the transactions. This is the ultimate requirement to
preserve database consistency. Locking and time-stamping are the mechanisms that enforce
serialisability.
Following are the mechanisms used to control concurrency:
 Pessimistic concurrency control or Locking
 Optimistic concurrency control

View and conflict serializability

Two major types of serializability exist: view-serializability, and conflict-serializability. Any


schedule that is conflict-serializable is also view-serializable, but not necessarily the opposite
is true.
Conflict Serializable: A schedule is called conflict serializable if it can be transformed into a
serial schedule by swapping non-conflicting operations.
Conflicting operations: Two operations are said to be conflicting if following conditions
satisfy.
i. They belong to different transactions
ii. They operate on the same data item
iii. At Least one of them is a write operation
Consider the below operations-
1. Ix = read(P), Iy = read(P). Ix and Iy don’t conflict.
2. Ix = read(P), Iy = write(P). They conflict.
3. Ix = write(P), Iy = read(P). They conflict.
4. Ix = write(P), Iy = write(P). They conflict.
T1 T2

Read(P)

Write(P)

Write(P)

The above schedule is not conflict serializable.

The outcome of above schedule is not equivalent of either <T1,T2> or <T2,T1>.

Hence a serial schedule TA follows TB, by a series of swaps of non-conflicting instructions


making the below Schedule conflict serializable.
TA TB
Read(X)
Write(X)

Read(X)
Write(X)

Read(Y)
Write(Y)
Read(Y)
Write(Y)

The above schedule is conflict serializable.

View serialisability: Two schedules are said to be view serializable if the transactions in both
the schedules execute similar actions in equivalent method. i.e., a schedule S is said to be
view serializable if it is view equivalent to a serial schedule.
S and S` are view equivalent if the following three conditions are met:
i. For each data item P, if transaction Ti reads the initial value of P in schedule S,
then transaction Ti must, in schedule S`, also read the initial value of P.
ii. For each data item P, if transaction Ti executes read (P)in schedule S, and that
value was produced by transaction Tj, then transaction Ti must in schedule S`
also read the value of P that was produced by transaction Tj.
iii. For each data item P, the transaction that performs the final write(P) operation
in schedule S must perform the final write(P) operation in schedule S`.

View equivalence is also based purely on reads and writes alone.


A schedule S is view serializable if it is ie w equivalent to a serial schedule.
Every conflict serializable schedule is also view serializable.
Every view serializable schedule which is not conflict serializable has blind writes.

TA TB TC
Read(X)

Write(X)

Write(X)

Write(X)

Locking Protocols:

Pessimistic Concurrency Control presumes that there occurs inconsistency. It detects and
resolves the inconsistency once they take place, using locking.
A ‘lock’ is method to control concurrent access to a data item in a database which depicts the
status of a data item pertaining to feasible operations which can be applied to that particular
item.
Normally, in a database there will be a lock for each data item. A data item can be locked in
two types: Binary locks and Exclusive (X)/ Shared (S) locks
i. In binary lock, a data item can be in two states either locked or unlocked.
ii. In X-lock, data item can be read and written as well. It is requested using lock-X
instruction.
iii. In S-lock, data item can only be read. It is requested using lock-S instruction.
A lock is used for synchronising the access to the database items through concurrent
transactions. Only after the access is granted, a transaction can be proceeded further
A locking protocol is a procedure followed by all transactions while requesting and releasing
locks, and controls the set of possible schedules.
Lock-compatibility matrix

The above matrix shows that a transaction can request shared mode lock on an item A even
though it is locked already by another transaction in shared mode. This is not possible with
any other mode-combination.
To access a data item, a transaction must first lock that item. If the data item is already locked
by another transaction in an incompatible mode, the concurrency-control manager will not
grant the lock until all incompatible locks held by other transactions have been released.
Example for a transaction performing locking:
T: lock-S(A)
Read (A);
unlock (A);
lock-S (B);
Read (B);
unlock (B);
display (A+B)

Locking as above is not sufficient to guarantee serializability. Because if A and B get updated
in-between the read of A and B, the displayed sum would be wrong. Instead do as follows.
T: lock-S(A)
Read (A);
lock-S (B);
Read (B);
display (A+B)
unlock (A);
unlock (B);
Deadlock due to locking
Locking can lead to an undesirable situation called deadlock. When deadlock occurs, the
system must roll back one of the two transactions. If we do not use locking, or if we unlock
items too soon after reading or writing them, we may get inconsistent states.
On the other hand, if we do not unlock a data item before requesting a lock on another data
item, deadlocks may occur.

Schedule leading to deadlock

Each transaction in the system has to follow a set of rules, called a locking protocol.
There are different types of locking protocols:
 Simplistic lock protocol
 Pre-claiming lock protocol
 Two-Phase locking (2PL) protocol
i. Conservative Two-Phase locking
ii. Strict Two-Phase locking
iii. Rigorous Two-Phase locking

Granting of locks

A transaction may never make progress to obtain a lock. Then it is said to be starved. To
avoid starvation of transactions, the concurrency-control manager grants lock provided.
a) There is no other transaction holding a lock on the item in a mode that conflicts with
requested mode.
b) There is no other transaction that is waiting in the QUEUE for lock on the item.
So earlier requested transaction will obtain the lock with a little wait may be.

Basic Two-Phase Locking Protocol

A transaction is said to follow 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 none can be released.
Shrinking Phase: Existing locks may be released but no new locks can be acquired.
Note – If lock conversion is allowed, then upgrading of lock( from S(a) to X(a) ) is allowed in
Growing Phase and downgrading of lock (from X(a) to S(a)) must be done in shrinking
phase.
2-PL ensures serializablity, but there are still some drawbacks of 2-PL.
 Cascading Rollback is possible under 2-PL.
 Deadlocks and Starvation is possible.

Cascading Rollback in 2-PL

Below schedule causes Dead lock in 2-PL


Schedule: Lock-X1(A) Lock-X2(B) Lock-X1(B) Lock-X2(A)
To overcome this problem, Strict 2-PL and Rigorous 2-PL are extensively used in
commercial databases.
1. Strict Two-phase locking (Strict-2PL)
 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.
 It does not have cascading abort as 2PL does.
Implication:
 Strict Two-Phase Locking Protocol avoids cascaded rollbacks.
 This protocol not only requires two-phase locking but also all exclusive-locks should
be held until the transaction commits or aborts.
 It is not deadlock free.
 It ensures that if data is being modified by one transaction, then other transaction cannot
read it until first transaction commits.

2. Rigorous Two-Phase Locking


 Rigorous Two – Phase Locking Protocol avoids cascading rollbacks.
 This protocol requires that all the share and exclusive locks to be held until the
transaction commits.

3. Conservative Two-Phase Locking Protocol


 Conservative Two – Phase Locking Protocol is also called as Static Two – Phase
Locking Protocol.
 This protocol is almost free from deadlocks as all required items are listed in advanced.
 It requires locking of all data items to access before the transaction starts.

Graph-Based Protocols

We’ve even seen that Deadlocks can be avoided if we follow Conservative 2-PL but the
problem with this protocol is it cannot be used practically. Graph Based Protocols are used as
an alternative to 2-PL. Tree Based Protocols is a simple implementation of Graph Based
Protocol.
A prerequisite of this protocol is that we know the order in which database items are accessed:
 Impose a partial ordering? on the set D = (d1,d2,…, dh) of all data items.
 If di —> dj, then any transaction accessing both di and dj must access di before
accessing dj.
 Implies that the set D may now be viewed as a directed a cyclic graph (DAG), called a
database graph.
The tree-protocol is a simple kind of graph protocol.
Tree based Protocol

 Only exclusive locks are allowed.


 The first lock by Ti may be on any data item. Subsequently, a data O can be locked by
Ti only if the parent of O is currently locked by Ti.
 Data items may be unlocked at any time.
 A data item cannot be re locked once it is unlocked.

The tree protocol ensures conflict serializability as well as freedom from deadlock. Unlocking
may occur earlier in the tree-locking protocol than in the two-phase locking protocol.
i. Shorter waiting times and increase in concurrency.
ii. Protocol is deadlock-free (no deadlock-related rollbacks).
iii. However, Cascading rollbacks due to transaction aborts are possible. However, a
transaction may have to lock data items that it does not access.
iv. Increased locking overhead and additional waiting time.
v. Potential decrease in Concurrency. Schedules not possible under two-phase locking are
possible under tree protocol, and vice versa.

Time Stamp based Protocol

This protocol uses either system time or logical counter as a timestamp. The timestamp-
ordering protocol ensures serializability among transactions in their conflicting read and write
operations. This is the responsibility of the protocol system that the conflicting pair of tasks
should be executed according to the timestamp values of the transactions.

 The timestamp of transaction Ti is denoted as TS(Ti).


 Read time-stamp of data-item X is denoted by R-timestamp(X).
 Write time-stamp of data-item X is denoted by W-timestamp(X).

Timestamp ordering protocol works as follows −


If a transaction Ti issues a read(X) operation −

If TS(Ti) < W-timestamp(X)


Operation rejected.
If TS(Ti) >= W-timestamp(X)
Operation executed.
All data-item timestamps updated.
If a transaction Ti issues a write(X) operation −

If TS(Ti) < R-timestamp(X)


Operation rejected.
If TS(Ti) < W-timestamp(X)
Operation rejected and Ti rolled back.
Otherwise, operation executed.

Thomas' Write Rule


This rule states if TS(Ti) < W-timestamp(X), 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.

To be Continued …

You might also like