Concurrency

Database Systems Lecture 15

Natasha Alechina
 In This Lecture
• Concurrency control
• Serialisability
• Schedules of transactions
• Serial & serialisable schedules
• Locks
• 2 Phase Locking protocol (2PL)
• For more information
• Connolly and Begg chapter 20
• Ullman and Widom chapter 8.6
Need for concurrency control
• Previous lecture: transactions running
concurrently may interfere with each other,
causing various problems (lost updates etc.)
• Concurrency control: the process of
managing simultaneous operations on the
database without having them interfere with
each other.
 Lost Update

T1 T2

Read(X)
X = X - 5
Read(X)
X = X + 5
This update Write(X)
Is lost Only this update
Write(X) succeeds
COMMIT
COMMIT
Uncommitted Update
(“dirty read”)
T1 T2

Read(X)
X = X - 5
Write(X)
Read(X) This reads
the value
X = X + 5
of X which
Write(X) it should
ROLLBACK not have
COMMIT seen
Inconsistent analysis

T1 T2

Read(X)
X = X - 5
Write(X)
Read(X)
Read(Y) Summing up
Sum = X+Y data while it is
Read(Y) being updated
Y = Y + 5
Write(Y)
 Schedules
• A schedule is a sequence of the operations
by a set of concurrent transactions that
preserves the order of operations in each of
the individual transactions
• A serial schedule is a schedule where
operations of each transaction are executed
consecutively without any interleaved
operations from other transactions (each
transaction commits before the next one is
allowed to begin)
 Serial schedules
• Serial schedules are guaranteed to avoid
interference and keep the database
consistent
• However databases need concurrent access
which means interleaving operations from
different transactions
 Serialisability
• Two schedules are equivalent if they always
have the same effect.
• A schedule is serialisable if it is equivalent to
some serial schedule.
• For example:
• if two transactions only read some data items,
then the order is which they do it is not important
• If T1 reads and updates X and T2 reads and
updates a different data item Y, then again they
can be scheduled in any order.
 Serial and Serialisable
Interleaved Schedule Serial Schedule
T1 Read(X) T2 Read(X)
T2 Read(X) T2 Read(Y)
T2 Read(Y) T2 Read(Z)
T1 Read(Z)
T1 Read(Y) T1 Read(X)
T2 Read(Z) T1 Read(Z)
T1 Read(Y)
This schedule is serialisable:
Conflict Serialisable Schedule
Interleaved Schedule Serial Schedule
T1 Read(X) T1 Read(X)
T1 Write(X) T1 Write(X)
T2 Read(X) T1 Read(Y)
T2 Write(X) T1 Write(Y)
T1 Read(Y)
T1 Write(Y) T2 Read(X)
T2 Read(Y) T2 Write(X)
T2 Write(Y) T2 Read(Y)
T2 Write(Y)
This schedule is serialisable,
even though T1 and T2 read
and write the same resources
X and Y: they have a conflict
 Conflict Serialisability
• Two transactions • A schedule is conflict
have a conflict: serialisable if
• NO If they refer to transactions in the
different resources schedule have a
• NO If they are reads conflict but the
• YES If at least one is schedule is still
a write and they use serialisable
the same resource
 Conflict Serialisability
• Conflict serialisable • Important questions:
schedules are the how to determine
main focus of whether a schedule
concurrency control is conflict serialisable
• They allow for • How to construct
interleaving and at conflict serialisable
the same time they schedules
are guaranteed to
behave as a serial
schedule
 Precedence Graphs
• To determine if a • Edge T1  T2 if in the
schedule is conflict schedule we have:
serialisable we use a • T1 Read(R) followed by
precedence graph T2 Write(R) for the
same resource R
• Transactions are
vertices of the graph • T1 Write(R) followed by
T2 Read(R)
• There is an edge from
T1 to T2 if T1 must • T1 Write(R) followed by
happen before T2 in T2 Write(R)
any equivalent serial • The schedule is
schedule serialisable if there are
no cycles
 Precedence Graph Example
• The lost update T1 T2
schedule has the
precedence graph: Read(X)
X = X - 5
Read(X)
T1 Write(X) followed by T2 Write(X)
X = X + 5
Write(X)
T1 T2 Write(X)
COMMIT
T2 Read(X) followed by T1 Write(X) COMMIT
 Precedence Graph Example
• No cycles: conflict T1 T2
serialisable schedule
Read(X)
T1 reads X before T2 writes X and
T1 writes X before T2 reads X and Write(X)
T1 writes X before T2 writes X Read(X)
Write(X)

T1 T2
 Locking
• Locking is a procedure used to control
concurrent access to data (to ensure
serialisability of concurrent transactions)
• In order to use a ‘resource’ (table, row, etc)
a transaction must first acquire a lock on
that resource
• This may deny access to other transactions
to prevent incorrect results
 Two types of locks
• Two types of lock
• Shared lock (S-lock or read-lock)
• Exclusive lock (X-lock or write-lock)
• Read lock allows several transactions
simultaneously to read a resource (but no
transactions can change it at the same time)
• Write lock allows one transaction exclusive
access to write to a resource. No other
transaction can read this resource at the same
time.
• The lock manager in the DBMS assigns locks and
records them in the data dictionary
 Locking
• Before reading from a • A transaction may not
resource a transaction acquire a lock on any
must acquire a read-lock resource that is write-
• Before writing to a locked by another
resource a transaction transaction
must acquire a write-lock • A transaction may not
• Locks are released on acquire a write-lock on a
commit/rollback resource that is locked
by another transaction
• If the requested lock is
not available, transaction
waits
 Two-Phase Locking
• A transaction follows • Two phases
the two-phase • Growing phase where
locking protocol locks are acquired on
(2PL) if all locking resources
operations precede • Shrinking phase
where locks are
the first unlock released
operation in the
transaction
 Example
• T1 follows 2PL
protocol T1 T2
• All of its locks are read-lock(X) read-lock(X)
acquired before it Read(X) Read(X)
releases any of them
write-lock(Y) unlock(X)
• T2 does not unlock(X) write-lock(Y)
• It releases its lock on Read(Y) Read(Y)
X and then goes on to
Y=Y+X Y=Y+X
later acquire a lock on
Y Write(Y) Write(Y)
unlock(Y) unlock(Y)
 Serialisability Theorem

Any schedule of two-phased

transactions is conflict serialisable
 Lost Update can’t happen with
2PL
T1 T2

read-lock(X) Read(X)
X = X - 5
Read(X) read-lock(X)
cannot acquire X = X + 5
write-lock(X): Write(X) cannot acquire
T2 has read- Write(X) write-lock(X):
lock(X) COMMIT T1 has
COMMIT read-lock(X)
 Uncommitted Update cannot
happen with 2PL
T1 T2

read-lock(X) Read(X)
X = X - 5
write-lock(X) Write(X) Waits till T1
Read(X) releases
X = X + 5 write-lock(X)
Write(X)
Locks released ROLLBACK
COMMIT
 Inconsistent analysis cannot
happen with 2PL
T1 T2

read-lock(X) Read(X)
X = X - 5
write-lock(X) Write(X)
Waits till T1
Read(X)
releases
Read(Y)
write-locks on
Sum = X+Y
X and Y
read-lock(Y) Read(Y)
Y = Y + 5
write-lock(Y) Write(Y)
 Next Lecture
• Deadlocks
• Deadlock detection
• Deadlock prevention
• Timestamping
• For more information
• Connolly and Begg chapter 20
• Ullman and Widom chapter 8.6