CHAPTER THREE

TRANSACTION MANAGEMENT AND

CONCURRENCY CONTROL

1 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Transaction Management
 A transaction is a logical unit of work on the database.

 It may be an entire program, a part of a program, or a single command and it

may involve any number of operations on the database.

 The DBMS has no inherent way of knowing which database access operations are

grouped together to form a single logical transaction.

 It must therefore provide a method to allow the user to indicate the boundaries of

a transaction.

 One way of specifying the transaction boundaries is by using keywords

Begin_Transaction and End_Transaction or their equivalence to delimit

2 Prepared BY: Abebe SH. (MSc.) 12/26/2023
transactions.
Transaction Management
 As a result , all database access operations between Begin_Transaction and

End_Transaction are considered as forming one transaction.

 If the data base operations in a transaction do not update the database but

only retrieve data, the transaction is called a read-only transaction.

 The basic database access operations that Transactions can include are:-

 read(X) :- Reads the value of a database item named X

 write(X):- writes the value of variable X in to the database

3 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Transaction State
 A transaction can have one of two outcomes.
A. Committed:-
 A transaction that completes its execution successfully is said to be committed.
 A committed transaction that has performed updates transforms the database into a
new consistent state, which must persist even if there is a system failure.
 A committed transaction cannot be aborted. If we decide that the committed
transaction was a mistake, we must perform another compensating transaction to
reverse its effects
 For instance, if a transaction added $20 to an account, the compensating
transaction would subtract $20 from the account.
B. Aborted:- if the transaction does not execute successfully.
 Thus, any changes that, the aborted transaction made to the database must be
undone.
 Once the changes caused by an aborted transaction have been undone, we say that
4 Prepared BY: Abebe SH. (MSc.) 12/26/2023
the transaction has been rolled back.
Transaction State
 A transaction must be in one of the following 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

 We say that a transaction has committed only if it has entered the committed state.

 Similarly, we say that a transaction has aborted only if it has entered the aborted state.

 5 A transaction is said
Prepared BY: Abebe to have terminated if has either committed or aborted.
SH. (MSc.) 12/26/2023
 Transaction State
 A transaction starts in the active state.
When it finishes its final statement, it
enters the partially committed state.
 At this point, the transaction has
completed its execution, but it is still
possible that it may have to be aborted,
since the actual output may still be
temporarily residing in main memory,
and thus a hardware failure may
preclude its successful completion
Figure, State transition diagram for a transaction

 A transaction enters the failed state after the system determines that the transaction can no
longer proceed with its normal execution (for example, because of hardware or logical
errors). Such a transaction must be rolled back. Then, it enters the aborted state.
6 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Properties of Transactions
 There are properties that all transactions should possess. The four basic, or so-called

ACID, properties of a transaction are;

A. Atomicity

– The ‘all or nothing’ property. A transaction is an indivisible unit that is either performed

in its entirety or is not performed at all.

 It is the responsibility of the recovery subsystem of the DBMS to ensure atomicity.

B. Consistency

– A transaction must transform the database from one consistent state to another consistent

state.
 It Prepared
is theBY: Abebe
responsibility
SH. (MSc.)
of both the DBMS and the application developers to ensure
7 12/26/2023
Properties of Transactions
C. Isolation.

– Transactions execute independently of one another. In other words, the partial

effects of incomplete transactions should not be visible to other transactions.

 It is the responsibility of the concurrency control subsystem to ensure isolation.

D. Durability.

The effects of a successfully completed (committed) transaction are permanently

recorded in the database and must not be lost because of a subsequent failure.
 It is the responsibility of the recovery subsystem to ensure durability.

8 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Concurrency Control
 In DBMS when multiple users are allowed to access the same data at the same
time it is referred to as Concurrency.
 The process to manage this concurrent access is called Concurrency Control in
DBMS.
 Concurrency can simply be said to be executing multiple transactions at a time.

 Concurrency Control is the method of managing concurrent operations on the

database without getting any obstruction with one another.
 It is a procedure in DBMS which helps us for the management of simultaneous
processes to execute without conflicts between each other, these conflicts occur in
multi Prepared
userBY:systems.
Abebe SH. (MSc.) 12/26/2023
9
Concurrency Control
 Concurrent access is relatively easy if all users are only reading data, as there

is no way that they can interfere with one another.

 However, when two or more users are accessing the database simultaneously

and at least one is updating data, there may be interference that can result in
inconsistencies.

 A major objective of developing a database is to enable many users to access

shared data concurrently.

10 Prepared BY: Abebe SH. (MSc.) 12/26/2023

The need for concurrent execution
 The following are some of the advantages of Concurrent Execution of Transactions;

 Improved throughput:- Number of transactions that can be executed in a given amount

of time is called as throughput.
 When we execute multiple transactions simultaneously that increases the transaction
throughput

 Reduced waiting time:- There may be a mix of transactions running on a system, some
short and some long.
 If transactions run serially, a short transaction may have to wait for a preceding long
transaction to complete, which can lead to unpredictable delays in running a transaction.

 Moreover, it also Reduces the average response time of transaction :the average time for a
transaction to be completed after it has been submitted.
11 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Problems arising due to concurrency
 Concurrency is of great advantage because of the above said reasons but when

there is multiple concurrent access to a single file in the database, then many
problems would arise in a DBMS.

 The three potential problems caused by concurrent execution of transactions are

 The lost update problem

 The uncommitted dependency problem, and

 The inconsistent analysis problem.

12 Prepared BY: Abebe SH. (MSc.) 12/26/2023

 A. The Lost Update Problem
 This problem arises when data which is being updated by one transaction is overwritten
by an update of another transaction.
 In these concurrent transactions
 Consider the following scenario
 At time t1 transaction 1 reads a value a from the
database.
 At time t2, transaction 2 reads the same value.
 At time t3 transaction 1 updates the value of a.
 And without the knowledge of the update done by
transaction 1, transaction 2 updates the value of a
at time t4.

 As a result, the update done by transaction 1 is overridden by the update performed by

transaction 2. This problem is known as a Loss Update Problem.
13 Prepared BY: Abebe SH. (MSc.) 12/26/2023
A. The Lost Update Problem
 Example 1: let us say we have a simple bank account x and its initial balance is 100 birr.
 In this Example,
 Transactions T1and T2 start at nearly the same
 At time t2, T2 read balance x as 100 birr
 At time t3, T1 read balance x as 100 birr and at the
same time T2 increases balance x by 100 to 200
birr
 At time t4, T1 decrements its copy by 10 to 90 birr
and at the same time T2 stores the update (200

 Latter, at time t5, T1 stores the change madebirr)

at t4 to the database. ( at time t5, T1
overwrites the update made by transaction
 The loss of T2’s update is avoided by preventing T1 from reading the value of balx until
14 Prepared BY: Abebe SH. (MSc.) 12/26/2023
after T2 ’s update has been completed.
B. The uncommitted dependency (or dirty read) problem
 The uncommitted dependency problem occurs when one transaction is allowed to see the
intermediate results of another transaction before it has committed or rollbacked.
 Consider the following scenario
 In these concurrent execution
 at time t1 transaction 2 reads the
value of a
 at time t2 transaction 2 updates the
value of a
 at time t3 transaction 1 reads the
uncommitted value of a. and
 at time t4 transaction 2 rollbacks its
update.
 This leads to a problem where transaction 1 reads the wrong value for a and executes
according to the wrong data. This will lead to incorrect output.

15 Prepared BY: Abebe SH. (MSc.) 12/26/2023

 B. The uncommitted dependency (or dirty read) problem
 Example 1:- let us use the bank account relation we have used on slide no. 14.
 In this example
 At time t1, T4 starts its operation
 At time t2, T4 read the value of balance x
as 100 birr and at time t3 it increases and
update balance x by 100 to 200 birr at time
t4.
 but it aborts the transaction at t5, so that
balance x should be restored to its original
value of 100 birr. However at the same
time t3 reads the new value of balance x
(200 birr) and
 At time t6, T3 decrements the value of
balance x (200 birr) by 10 and store its
balance to the database.
 This problem is avoided by preventing T3 from reading balance x until after the decision
has
16 been made
Prepared to either
BY: Abebe SH. (MSc.)commit or abort T4’s effects. 12/26/2023
 C. The Inconsistent Analysis Problem
 The problem of inconsistent analysis occurs when a transaction reads several values from the
database but a second transaction updates some of them during the execution of the first.
 Example:- One example is illustrated in the following table, in which a summary transaction
T6 is executing concurrently with transaction T5.
 Transaction T6 is totaling the balances of account x(100 birr), account y(50 birr), and account
z(25 birr).
 However, in the
meantime, transaction T5
has transferred 10 birr
from balx to balz, so that
T6 now has the wrong
result (10 birr too high).
 This problem is avoided
by preventing transaction
T6 from reading balx and
balz until after T5 has
17 Prepared BY: Abebe SH. (MSc.) completed its updates.
12/26/2023
 Serializability
 The objective of a concurrency control is to schedule transactions in such a way as to avoid any
interference between them, and hence prevent the types of problem described in the previous
section.
 One obvious solution is to allow only one transaction to execute at a time: one transaction is
committed before the next transaction is allowed to begin.
 However, the aim of a multi-user DBMS is also to maximize the degree of concurrency or
parallelism in the system, so that transactions that can execute without interfering with one
another can run in parallel.
 For example, transactions that access different parts of the database can be scheduled together
without interference.
 In this section, we examine serializability as a means of helping to identify those executions of
transactions
18 Preparedthat areSH.guaranteed
BY: Abebe (MSc.) to ensure consistency. 12/26/2023
Serializability in DBMS
 Serializability in DBMS is the method which helps in identifying those executions of

transactions that guarantee to ensure consistency in the database.

 But before understanding the concept of Serializability, we need to have knowledge

about what a schedule actually is in DBMS.

 Schedule (History of Transaction) is the sequence of read and / or write operation

followed by commit or abort action.

 Example. Say we have two transactions T1 and T2. let,

 Transaction T1 Transfers 100 birr from account A to account B.

 On the other hand, transaction T2 Transfer 200 birr from account B to account C. The

set of operations in these transactions would be as follows:

19 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Serializability in DBMS
 For the purpose of recovery and concurrency control,
we are mainly interested in the read and write
operations of the transactions as well as the commit
and abort operations.
 A short hand notation for describing a schedule uses
the symbols r, w, c, and a for the operations read,
write, commit, and abort, respectively, and appends a
subscript the transaction id (transaction number)to
each operation in the schedule.
 As a result, the schedule for this table can be written
as, (let us call the schedule S1)
 S1: r1(acc A);w1(acc A); r1(acc B); w1(acc B);
c1;r2(acc B);w2(acc B); r2(acc C);w2(acc C);c2;
20 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Types of Schedules

21 Prepared BY: Abebe SH. (MSc.) 12/26/2023

 Types of Schedules
 Schedule can be either

i. Serial Schedule the operations of each transaction are executed consecutively

without any interleaved operations from other transactions.
 In a serial schedule, only one transaction at a time is active and the commit (or abort)

of the active transaction initiates execution of the next transaction.

ii. Non-serial Schedules, operations from a set of concurrent transactions are
interleaved.
 The problems are resulted from the mismanagement of concurrency.

 Serial execution prevents such problems occurring.

 Non-serial schedules can be either Serializable or Non-serializable schedule

22 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Types of Schedules

23 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Finding number of schedules
 If we have n number of transactions T1, T2, T3,…., Tn and N1,N2,N3,….,Nn

number of operations respectively. then

The total number of possible schedules (serial and non-serial) is given by:-

Number of Serial Schedules (Number of different ways of arranging T

transactions) are= T!
Non serial schedules= total schedules- serial schedules

24 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Serializable Schedule
 The objective of serializability is to find non-serial schedules that allow transactions to

execute concurrently without interfering with one another, and thereby produce a
database state that could be produced by a serial execution.

 Notice

 There are n! possible serial schedules of n transactions and many more possible non-

serial schedules. We can form two disjoint groups of the non-serial schedules:
 Those that are equivalent to one (or more) of the serial schedules, and hence are

serializable; and
 Those that are not equivalent to any serial schedule and hence are not serializable.

 There are two types of Serializable schedules

25 Prepared BY: Abebe SH. (MSc.) 12/26/2023
 Conflict Serializable and View Serializable
Serializability
 Exercise 1: Given the following two transactions, and assuming that initially x = 3, and

y =2.

A. how many possible total, serial and non serial number of schedules are there?
B. Create all possible serial schedules and examine the values of x and y;

C. Create some non-serial schedule and examine the values of x and y. identify

26
serializable schedules?
Prepared BY: Abebe SH. (MSc.) 12/26/2023
Serializability
 When transactions are running concurrently the operations may conflict each other. Such operations

are said to be conflicted operations.

 The conflicted operations must satisfy all of the following conditions:

– Operations must belong to different transactions.

– Operations must access the same data item.

– At least one of the operations is a write operation

– Example :- given the following schedule; S1: r1(X);r2(X);w1(X);r1(Y);w2(X);w1(Y)

 the operations rl(X) and w2(X) conflict, as do the operations r2(X) and w1(X), and the operations
w1(X) and w2(X).
 However, the operations rl(x) and r2(x) do not conflict, since they are both read operations;
 The operations w2(X) and w1(y) do not conflict, because they operate on distinct data items X and
Y; and
 The operations rl(x) and w1(X) do not conflict, because they belong to the same transaction.
27 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Conflict serializable
 Two schedules are said to be conflict equivalent if the order of any two conflicting
operations is the same in both schedules.
 Example 1: Consider the following two schedules and determine whether they are
conflicting equivalent?

28 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Conflict serializable
 Exercise 1: Consider the following two schedules and determine whether they are

conflicting equivalent?

Schedule 1
Schedule 2

 Q1. Identify all possible conflicting operations in both schedules?

 Q2. Determine whether these two schedules are conflict equivalent?
29 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Conflict serializable

 Using the notion of conflict equivalence,

 If a given non-serial schedule can be converted into a serial schedule by

swapping its non-conflicting operations, then its called conflict

serializable schedule.

30 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Conflict serializable
 Example:- Consider the schedule S1 shown in the following figures containing operations from two
concurrently executing transactions T7and T8 .
 Since the write operation on balx in T8 does not conflict with the subsequent read operation on baly in T7,
we can change the order of these operations to produce the equivalent schedule S2 shown below.
 If we also now change the order of the following non-conflicting operations,
 Change the order of the write(balx) of T8 with the write(baly) of T7.
 Change the order of the read(balx) of T8 with the read(baly) of T7.
 Change the order of the read(balx) of T8 with the write(baly) of T7.

31 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Schedule S1 Schedule S2 Schedule S3
Exercise
 Given the following schedule and determine the schedule is conflict serializable?

32 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Testing for Conflict Serializability of a schedule
 There is a simple algorithm for determining the conflict serializability of a schedule.

 The algorithm looks at only the read_item and write_item operations in a schedule to
construct a precedence graph (or serialization graph), which is a directed graph G=(N,E)
that consists of a set of nodes N and a set of directed edges E. which is constructed as
follows:
1. Create a node for each transaction.
2. Create a directed edge Ti →Tj, if Tj reads the value of an item written by Ti.
3. Create a directed edge Ti →Tj, if Tj writes a value into an item after it has been read by Ti.
4. Create a directed edge Ti →Tj, if Tj writes a value into an item after it has been written by
Ti.
5. The schedule S is conflict serializable if and only if the precedence graph has no cycles.
33 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Testing for Conflict Serializability of a schedule
 If there is no cycle in the precedence graph, we can create an equivalent serial schedule

S’ that is equivalent to S, by ordering the transactions that participate in S.

 However, if the precedence graph has a cycle, it is easy to show that we can not create

any equivalent serial schedule, so S is not serializable.

 Example1: draw precedence graph for the following schedule and check whether it is

conflict serializable?
 S= r1(x); r2(x);w1(x);r1(y);w2(x);w1(y).

34 Prepared BY: Abebe SH. (MSc.) 12/26/2023

 Testing for Conflict Serializability of a schedule
 Example 2: consider the following schedules and determine whether the schedules are
conflict serializable using precedence graph.

List all the conflicting operations and determine

the dependency between the transactions-
 R2(X) , W3(X) (T2 → T3)
 R2(X) , W1(X) (T2 → T1)
 W3(X) , W1(X) (T3 → T1)
 W3(X) , R4(X) (T3 → T4)
 W1(X) , R4(X) (T1 → T4)
 W2(Y) , R4(Y) (T2 → T4)

35 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Schedule 1.
 Testing for Conflict Serializability of a schedule
 Exercise : consider the following schedules and determine whether the schedules are
conflict serializable using precedence graph. Schedule 2.
Schedule 1.

S1 : R1(A) , R2(A) , R1(B) , R2(B) , R3(B) , W1(A)

, W2(B)

36 Prepared BY: Abebe SH. (MSc.) 12/26/2023

View Equivalence and View Serializable
 Two schedules (Schedule1 and Schedule2) are said to be view equivalence if they
follow the following three conditions
1. For each data item x, First read should be performed by the same transaction in
both schedules.
2. For each data item x, Last write should be performed by the same transaction in
both schedules.
3. For each data item X, if transaction Ti executes read(X) in schedule S1, and if that
value was produced by a write(X) operation executed by transaction Tj, then the
read(X) operation of transaction Ti must, in schedule S2 ,also read the value of X
that was produced by the same write(X) operation of transaction Tj.

37 Prepared BY: Abebe SH. (MSc.) 12/26/2023

View Equivalence and View Serializable
 Example:- Consider the following two schedules (schedule1 and schedule2) and
determine whether they are view serializable?

38 Prepared BY: Abebe SH. (MSc.) 12/26/2023

View Equivalence and View Serializable
 The concept of view equivalence leads to the concept of view serializability.

We say that a schedule S is view serializable if it is view equivalent to a serial

schedule.

 In our previous example (see, slide no 38), schedule 1 is view serializable

schedule. Because it is view equivalence to serial schedule (schedule 2).

 Note

Every conflict-serializable schedule is also view serializable, but there are

view serializable schedules that are not conflict serializable.

39 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Non-Serializable schedule
 A non-serial schedule which is not serializable is called as non-serializable

schedule.

 The non-serializable schedule is divided into two types, Recoverable and

Non-recoverable Schedule.
A. Recoverable schedule
B. Non-recoverable schedule

40 Prepared BY: Abebe SH. (MSc.) 12/26/2023

A. Recoverable schedule
 A recoverable schedule is one where, 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 commit
operation of Tj.

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

41 Prepared BY: Abebe SH. (MSc.) 12/26/2023
A. Recoverable schedule
 Recoverable schedules are further categorized into three types:

I. Cascading Schedule
II. Cascadeless Schedule
III. Strict Schedule

42 Prepared BY: Abebe SH. (MSc.) 12/26/2023

I. Cascading Schedule
 If in a schedule, several other dependent transactions

are forced to rollback/abort because of the failure of

one transaction, then such a schedule is called as
Cascading Schedule

 Transaction T2 depends on transaction T1 and

transaction T3 depends on transaction T2.

 Thus, in this schedule, the failure of transaction T1 will

cause transaction T2 to rollback and similar case for

transaction T3.

 Therefore, it is a cascading schedule.

43 Prepared BY: Abebe SH. (MSc.) 12/26/2023
II. Cascadeless Schedule
 If in a schedule, a transaction is not allowed to read a

data item, until and unless the last transaction that has
written is committed/aborted, then such a schedule is
called as Cascadeless Schedule.

 It avoids cascading roll back and thus saves CPU time.

 To prevent cascading rollbacks, it disallows a

transaction from reading uncommitted changes from
another transaction in the same schedule.

 Here, the updated value of X is read by transaction T2

only after the commit of transaction T1. Hence, the

44 Prepared BY: Abebe SH. (MSc.) 12/26/2023
schedule is Cascadeless schedule.
III.Strict Schedule
 If in a schedule, until the last transaction that

has written it is committed or aborted, a

transaction is neither allowed to read nor
write data item, then such a schedule is called
as Strict Schedule.

 Here, transaction Tb reads/writes the written

value of transaction Ta only after the

transaction Ta commits. Hence, the schedule
is a strict schedule.

45 Prepared BY: Abebe SH. (MSc.) 12/26/2023

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

46 Prepared BY: Abebe SH. (MSc.) 12/26/2023

B. Non-Recoverable Schedule
 Consider the following schedule

involving two transactions T1 and

T2.

 T2 read the value of A written by

T1, and committed.

 T1 might later abort/commit,

therefore the value read by T2 is
wrong, but since T2 committed,
this schedule is non-recoverable.
47 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Concurrency Control Techniques
 Concurrency control is provided in a database to:

 Enforce isolation among transactions.

 Preserve database consistency through consistency preserving execution of

transactions.
 Resolve read-write and write-read conflicts.

 There are two main concurrency control techniques that allow transactions to execute

safely in parallel subject to certain constraints:

 locking and

 Timestamp methods.

48 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Locking Method
 Locking is A procedure used to control concurrent access to data. When one transaction

is accessing the database, a lock may deny access to other transactions to prevent
incorrect results.

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

 Several types of locks are used in concurrency control. Some of them are;

Binary Locks

Shared/ Exclusive Locks

Two-Phase Locking (2-PL)

49 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Binary Locks
 A binary lock has two states or values associated with each data item. These
values are:
– Locked or 1
– Unlocked or 0

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

 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
Prepared BY: Abebe SH. (MSc.)
50 LOCK(X) 12/26/2023
to 0 (unlocks the item) so that X may be accessed by other transactions.
Binary Locks
 When the binary locking scheme is used, every transaction must obey the following

rules:
– A transaction T must issue the operation lock_item(X) before any read_item(X) or

write_item(X) operations are performed in T.

– A transaction T must issue the operation unlock_item(X) after all read_item(X) and

write_item(X) operations are completed in T.

– A transaction T will not issue a lock_item(X) operation if it already holds the lock on

item X.
– A transaction T will not issue an unlock_item(X) operation unless it already holds the

lock on item X.
51 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Shared/ Exclusive Locks
 The preceding binary locking scheme is too restrictive for database items, because at most one
transaction can hold a lock on a given item.
 We should allow several transactions to access the same item X if they all access X for
reading purposes only.
 However, if a transaction is to write an item X, it must have exclusive access to X.

 For this purpose, a different type of lock called shared/ Exclusive lock is used.

 In shared/ exclusive locking method there are two locks. These are

 Shared Lock (S):- If a transaction has a shared lock on a data item, it can read the item but
not update it. and
 Exclusive Lock (X):- If a transaction has an exclusive lock on a data item, it can both read
and update the item.
52 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Shared/ Exclusive Locks
 Since read operations cannot conflict, it is permissible for more than one transaction to hold

shared locks simultaneously on the same item.

 On the other hand, an exclusive lock gives a transaction exclusive access to that item. Thus, as

long as a transaction holds the exclusive lock on the item, no other transactions can read or update
that data item.

 Shared/Exclusive Locks are used in the following way:

 Any transaction that needs to access a data item must first lock the item, requesting a shared lock

for read only access or an exclusive lock for both read and write access.
 If the item is not already locked by another transaction, the lock will be granted

 If the item is currently locked, the DBMS determines whether the request is compatible with the

existing lock. If a shared lock is requested on an item that already has a shared lock on it, the
53 Prepared BY: Abebe SH. (MSc.) 12/26/2023
request will be granted; otherwise, the transaction must wait until the existing lock is released.
Shared/ Exclusive Locks
 The following table (compatibility matrix) shows which type of lock requests can be

granted simultaneously.

54 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Two-Phase Locking (2-PL)
 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:

 Growing Phase:- This phase is also known as the first phase or the expanding

phase.
– In this phase that the transaction acquires all the locks needed by it but it cannot

release any locks here.

 Shrinking Phase:- This phase is also known as the second phase or the contracting

phase.
– Here a transaction is not allowed to acquire any new locks but it
55 Prepared BY: Abebe SH. (MSc.) 12/26/2023
can release the existing locks it holds.
Two-Phase Locking (2-PL)
 Let’s see the transaction implementing 2PL

 This sample execution of two concurrent

transactions shows how unlocking and locking
work with 2-pl.
 Note
 For transaction 1
 The growing phase is from time 1-3 and
 The shrinking phase is from time 5-7
 Lock point at time 3
 For transaction 2
 The growing phase is from time 2-6 and
 The shrinking phase is from time 9-10
 Lock point at time 6
 The lock point is the point at which the growing
phase ends.
56 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Two-Phase Locking (2-PL)
 Example: Transactions T1 and T2 shown below do not follow the two-phase locking
protocol. This is because the write_lock (X) operation follows the unlock (Y) operation in
T1 and similarly the write_lock (Y) operation follows the unlock (X) operation in T2.

 It can be proved that, if every transaction in a

schedule follows the two-phase locking
protocol, the schedule is guaranteed to be
serializable, obviating the need to test for
serializability of schedules any more.
 Enforcing two-phase locking rules is also
enforces serializability.

57 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Types Of Two-Phase Locking (2-PL)
 There are a number of variations of two-phase locking (2PL). The three well known types of 2-PL
techniques are;
Strict 2-PL

 In this variation, a transaction T does not release any of its exclusive (write) locks until after
it commits or aborts.
 Hence, no other transaction can read or write an item that is written by T unless T has
terminated (Committed/ Aborted).
 Strict 2-PL is not dead lock-free

Rigorous 2-PL

 A more restrictive variation of strict 2PL is rigorous 2PL.

 In this variation, a transaction T does not release any of its locks (exclusive or shared) until
after it commits or aborts, and so it is easier to implement than strict 2pL.
58 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Types Of Two-Phase Locking (2PL)
 Conservative 2-PL (also called Static 2-PL)
 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 2PLis a deadlock-free protocol

 Notice the difference between conservative and rigorous 2PL;

 Conservative 2-pl must lock all its items before it starts once the transaction starts it is in its shrinking
phase,
 whereas the latter (rigorous-2PL) does not unlock any of its items until after it terminates (by
committing or aborting) so the transaction is in its expanding phase until it ends.
59 Prepared BY: Abebe SH. (MSc.) 12/26/2023
Timestamp-Based Protocols
 Each transaction is issued a timestamp when it enters the system. If an old
transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-stamp
TS(Tj) such that TS(Ti) <TS(Tj).
 The protocol manages concurrent execution such that the time-stamps determine
the serializability order.
 In order to assure such behavior, the protocol maintains for each data Q two
timestamp values:
 W-timestamp(Q) is the largest time-stamp of any transaction that executed
write(Q) successfully.
 R-timestamp(Q) is the largest time-stamp of any transaction that executed
read(Q) successfully.

60 Prepared BY: Abebe SH. (MSc.) 12/26/2023

Dealing with Deadlock
 Deadlock is an unwanted situation in which two or more transactions are waiting

indefinitely for one another to give up locks.

 Deadlock is said to be one of the most feared complications in DBMS as it brings

the whole system to a Halt.

 When a database is stuck in a deadlock, It is always better to avoid the deadlock

rather than restarting or aborting the database.

 The deadlock avoidance method is suitable for smaller databases whereas the

deadlock prevention method is suitable for larger databases.

61 Prepared BY: Abebe SH. (MSc.) 12/26/2023

 Deadlock Avoidance
 Aborting a transaction is not always a practical approach. Instead, deadlock

avoidance mechanisms can be used to detect any deadlock situation in

advance.

 Methods like "wait-for graph" are available but they are suitable for only

those systems where transactions are lightweight having fewer instances of

resource.

 A wait-for graph is a directed graph used for deadlock detection in operating

systems and relational database systems.

62 Prepared BY: Abebe SH. (MSc.) 12/26/2023

63 Prepared BY: Abebe SH. (MSc.) 12/26/2023