Faculty of Business Administration

Database I
CSIS2300
Faculty of Business Administration

Concurrency Control
 Concurrency Control Techniques
• Objectives are…
▪ Understand transactions.
▪ Understand the need for concurrency control.
▪ Understand serial and serializable schedules.
▪ Understand the need for locks and locking protocols.

3
 Introduction

• Transaction Processing Systems are systems with

large DBs and hundreds of concurrent users that are
executing DB transactions.
• They require high availability and fast response time.
• A transaction represents a logical unit of DB
processing that must be completed in its entirety to
ensure correctness.

4
 Introduction (cont’d)

• “Ensure correctness” means preserving the

consistency of the DB.
• Therefore, we must ensure that
▪ All instructions in a transaction are executed to
completion, OR
▪ None are performed (rolled back).

5
 Introduction (cont’d)

• A transaction must be in one of the following states:

▪ Active
▪ Partially committed
▪ Failed
▪ Aborted
▪ Committed

6
 Schedules

• The order of execution of operations from various

transactions executing concurrently in an interleaved
fashion.

7
 Serializability of Schedules
• Schedules that are considered correct when concurrent
transactions are executing.

8
 Two Sample Transactions

T1 T2

read_item(X); read_item(X);
X:=X-N;
X:=X+M;
write_item(X);
write_item(X);
read_item(Y);
Y:=Y+N;
write_item(Y);

9
 No Interleaving Schedule A
Time
T1
read_item(X);
X:=X-N;
write_item(X);
read_item(Y);
Y:=Y+N;
write_item(Y);

T2

read_item(X);

X:=X+M;

write_item(X);

10
 No Interleaving Schedule B
Time

T2
read_item(X);
X:=X+M;
T1 write_item(X);
read_item(X);
X:=X-N;
write_item(X);
read_item(Y);
Y:=Y+N;
write_item(Y);

11
 Serial Schedules

• Lets try an example…

▪ Suppose at the beginning X=90 and Y=90
▪ And M=2 and N=3

12
 Schedule B Example
Time

T2
read_item(X=90);
X:=(X=90)+(M=2);
T1 write_item(X=92);
read_item(X=92);
X:=(X=92)-(N=3);
write_item(X=89);
read_item(Y=90);
Y:=(Y=90)+(N=3);
write_item(Y=93);

13
 Serial Schedules

• Schedule A and B were serial schedules.

14
 Serial Schedules

• Only one transaction is active at a time.

• Commit or abort starts next transaction.
• No interleaving.
• Transactions assumed independent and therefore
considered correct.
• Does not matter which transaction is first as long
as…
▪ Executed from beginning to end.
▪ NO interference from other operations.

15
 Serial Schedules

Disadvantages...
▪ Must wait (long time) for other transactions to end;
▪ Prevents CPU from time sharing while waiting (for I/O
e.g.);
▪ Therefore generally NOT acceptable in practice.

16
 Serial Schedules

• Schedule A and B were serial schedules.

• Now consider non-serial Schedules C and D coming
up.

17
 Interleaving Schedule C
Time
T1 T2
read_item(X);
X:=X-N;
read_item(X);
X:=X+M;

write_item(X);
read_item(Y);
write_item(X);

Y:=Y+N;
write_item(Y);

18
 Interleaving Schedules

• Lets try an example with values…

▪ Suppose at the beginning X=90 and Y=90
▪ And M=2 and N=3

19
 Interleaving Schedule C
Time
T1 T2
read_item(X=90);
X:=(X=90)-(N=3);
read_item(X=90);
X:=(X=90)+(M=2);

write_item(X=87);
read_item(Y=90);
write_item(X=92);

Y:=(Y=90)+(N=3);
write_item(Y=93);

20
 Interleaving Schedule D
Time
T1 T2
read_item(X);
X:=X-N;
write_item(X);

read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
Y:=Y+N;
write_item(Y);

21
 Interleaving Schedules

• Lets try an example with values…

▪ Suppose at the beginning X=90 and Y=90
▪ And M=2 and N=3

22
 Interleaving Schedule D
Time
T1 T2
read_item(X=90);
X:=(X=90)-(N=3);
write_item(X=87);

read_item(X=87);
X:=(X=87)+(M=2);
write_item(X=89);
read_item(Y=90);
Y:=(Y=90)+(N=3);
write_item(Y=93);

23
 Serializability

• Schedule C has “lost update” problem.

• Schedule D is correct.
• How to determine which non-serial schedule always
gives correct result ?
• Concept used is called Serializability of Schedules.

24
 Serializability

• A schedule S of n transactions is serializable if it is

equivalent to some serial schedule of the same n
transactions.
• In other words if Schedule C were to produce the
same results as either Schedule A or B then we
would say Schedule C is serializable.
• Serializable is distinct from being serial.

25
 Precedence Graphs

▪ Precedence graphs are drawn to determine

serializability.
• If the PG has a cycle, then the schedule is NOT
serializable
• Otherwise, the serializability order can be obtained
through topological sorting
▪ Test for Conflict Serializability is as explained below
▪ The set of edges consists of all edges Ti → Tj for
which one of the following three conditions hold
• Ti executes write(Q) before Tj executes read(Q)
• Ti executes read (Q) before Tj executes write (Q)
• Ti executes write(Q) before Tj executes write(Q)
▪ Next slide is an example. Schedule A - edge from T1 to
T2 is shown bec all the instructions of T1 are executed
before the first instruction of T2. 26
 Precedence Graphs

T1 T2

Schedule A

T2 T1

Schedule B

27
 Precedence Graphs: an Example
Time
T3
read_item(A);
A := A-50; T4

read_item(A);
temp := A * 0.1;
A := A - temp
write_item(A);
read_item(B)
write_item(A);
read_item(B); See Slide 26 for conditions.
B := B + 50; Red arrow= Condition 2
write_item(B); Green arrow= Condition 3
Condition 1 not shown
B := B + temp
write_item(B);

28
 Precedence Graphs

T3 T4

Previous schedule has a

cycle so not serializable

29
 Precedence Graphs
More examples

T1 T2 PG has a
cycle so
not
serializable

T4 T3

30
 Precedence Graphs
More examples

T1 T2 PG is
serializable

T4 T3

31
 Precedence Graphs
Topological Sorting

T1 T2 Pick a
node with
NO edges
going into
it, left
with…

T4 T3

32
 Precedence Graphs
Topological Sorting

T1 T2 Pick a
node with
NO edges
going into
it, left
with…

T4

33
 Precedence Graphs
Topological Sorting

T2

Therefore
serializability order is :
T3→T1 → T2 →T4.
It is possible to have
T4 more than one
serializability order.

34
 Transaction Support in SQL
• A single SQL statement is always considered atomic
– either it completes execution without error or it fails.
• ANSI SQL has no explicit Begin_Transaction
statement.
• But every transaction must have Commit or Rollback.

35
 Concurrency Control Techniques
• Techniques used to ensure noninterference or
isolation property of concurrently executing
transactions.
• Most techniques ensure serializability of schedules
using protocols.
• Locking protocols are used in most commercial
DBMSs.
• Also Timestamping protocol, et al.

36
 Locking Protocol

• A Lock is a variable associated with a data item

• It describes the status of the item with respect to possible
operations that can be applied to it e.g. read-only, write,
lock
• Generally, one lock per data item.

37
 Manual Locking

• In (Oracle) SELECT query rows are NOT locked

• During query changes, rows remain locked until
COMMITed
• To view rows and lock them for future changes, you
use,
SELECT – FOR UPDATE

38
 Manual Locking (cont’d)
• Syntax is:

SELECT columnnames
FROM tablenames
WHERE condition
FOR UPDATE OF columnnames
[NOWAIT]

• columnname does NOT imply that the entire column is

locked, just the rows
• NOWAIT is optional and informs user that the rows
requested have already been locked by another user.

39
 Binary Locks (Auto)

• Have TWO states: Locked (1) & Unlocked (0)

• Locked data item cannot be accessed by a requesting DB
operation
• No interleaving allowed once Lock or Unlock operation
started until operation terminates or the transaction waits.

40
 Binary Locks (cont’d)

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

41
 Binary Locks (cont’d)

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

42
 Binary Locks: an Example (pseudo-code)

T1 T2
read_lock(X);
read_lock(Y);
read_item(X);
read_item(Y); unlock(X);
unlock(Y); write_lock(Y);
write_lock(X); read_item(Y);
Y:=X+Y;
read_item(X);
write_item(Y);
X:=X+Y; unlock(Y);
write_item(X);
unlock(X);
43
 Binary Locks

• Initial Values: X=20, Y=30.

• Execute T1 then T2 (serial schedule):
▪ X=50
▪ Y=80
• Execute T2 then T1 (serial schedule):
▪ X=70
▪ Y=50
• Ans: Y in T1 and X in T2 unlocked too early.

44
 Shared/Exclusive Locks (Auto)

• Locks by themselves are insufficient as previous

example shows
• Furthermore, Binary Lock too restrictive; at most one
transaction can hold a lock on a given item
• S/E Lock have three states: Read(Shared) Lock,
Write(Exclusive) Lock, Unlock
• But even this is insufficient.

45
 Non-serializable Schedule
Time
T1
T2
read_lock(Y=30);
read_item(Y);
unlock(Y); read_lock(X=20);
read_item(X);
unlock(X);
write_lock(Y=30);
read_item(Y);
Y:=(X=20)+(Y=30);
write_item(Y=50);
unlock(Y); cont’d next page

46
 Non-serializable Schedule
from prev page Time
T1 T2
write_lock(X=20);
read_item(X);
X:=(X=20)+(Y=30);
write_item(X=50);
unlock(X);

Note: Y was read into memory very

early by T1 and remains in
memory. Unlock does not free
memory.

47
 Two-Phase Locking (Auto)
• ALL locking operations (read, write) precede the first
unlock operation
• Growing Phase
▪ New locks acquired, none released
• Shrinking Phase
▪ Acquired locks released, no new locks can be acquired.

48
 Two-Phase Locking: Rewritten

T1 T2
read_lock(X);
read_lock(Y);
read_item(X);
read_item(Y); write_lock(Y);
write_lock(X); unlock(X)
read_item(Y);
unlock(Y)
Y:=X+Y;
read_item(X);
write_item(Y);
X:=X+Y; unlock(Y);
write_item(X);
unlock(X);
49
 Two-Phase Locking

• Lock point : point in schedule S where transaction

obtained its final lock
• Thus ordering of lock points becomes serializability
ordering for the transactions
• Locking in two phases guarantees serializability
• 2 PL does NOT ensure freedom from deadlocks (e.g.
previous slide).

50
 Deadlocks

• Deadlock occurs when two (or more) transactions cannot

proceed with normal execution due to locking
• Example follows.

51
 Deadlock Example
T1 Time
lock-X(B); T2 issues request. Waiting
read(B) for T1 to release.
B := B - 50; T2
write(B);

lock-S(A);
read(A)
lock-S(B);
lock-X(A); Requests for locks pending.
T1 issues request. Waiting Transactions deadlocked.
for T2 to release.

52
 Deadlocks

• Deadlocks are a necessary evil

• Deadlocks preferable to inconsistent state
• To avoid must follow set of rules called locking protocol
• When deadlock occurs must rollback one of the two
transactions.

53
 Timestamping

• In 2PL, waiting occurs for requested item if already

locked
• TS do not use locks so deadlocking cannot occur
• A timestamp is a unique identifier created by the
DBMS to identify a transaction
• Serializability is enforced by ordering transactions
based on their timestamps.

54
 Timestamping (cont’d)

• TS uses current date/time value of the system clock

• Equivalent serial schedule has the transactions in
timestamp value order; called timestamp ordering (TO)
• TO algorithm must protect serializability order of item
access by conflicting operations
• The timestamps of the transactions determine their
serializability order. Thus if TS(Ti) < TS(Tj), then the
system must ensure that the produced schedule is
equivalent to a serial schedule in which transaction Ti
appears before transaction Tj.

55
 Timestamping (cont’d)

• To do this each DB item associated with two

timestamp (TS) values:
▪ Read_TS(X): The read timestamp
▪ Write_TS(X): The write timestamp
• The timestamp of transactions determine the
serializability order.
▪ If TS(Ti) < TS(Tj), then the scheme ensures that the
schedule is equivalent to Ti->Tj.
▪ If the order is violated, then the transaction is rolled
back.

56
 Timestamping (cont’d)

• The following are kept for each data item X:

▪ Read_TS(X): the largest timestamp (most recent) of
any transaction that successfully executed read(Q)
▪ Write_TS(X): the largest timestamp (most recent) of
any transaction that successfully executed write(Q)

57
 Timestamping (cont’d)

• The protocol operates as follows:

▪ When Ti issues read(X)
• If TS(Ti) < Write_TS(X), reject read, roll back Ti
• If TS(Ti) >= Write_TS(X), execute read,
– set (X) to MaxOf(read(X) or TS(Ti))
▪ Example
• Ti 00:02 < (X w00:03), reject read, roll back Ti
• Ti 00:02 >= (X w00:01), execute read,
set X r00:02 or systime
▪ It means that an earlier transaction is trying to read a
value of an item that has been updated by a (younger)
later transaction
▪ MaxOf() means that may be someone else who read it
after you started – you must preserve that value for 58
 Timestamping (cont’d)

• The protocol operates as follows:

▪ When Ti issues read(X)
• If TS(Ti) < Write_TS(X), reject read, roll back Ti and
reject the operation. This should be done because some
younger transaction with timestamp greater (more
recent) than TS(Ti) – and hence after Ti in the timestamp
ordering – has already written the value of item X before
Ti had a chance to read X.
• When Ti rolled back, Ti is issued new time stamp.

59
 Timestamping (cont’d)

• The protocol operates as follows:

▪ When Ti issues write(X)
• If TS(Ti) < Read_TS(X), reject write, roll back Ti
• If TS(Ti) < Write_TS(X), reject write, roll back Ti
• Otherwise execute write set (X) to TS(Ti)
▪ Example
• Ti 00:02 < (X r00:03), reject write, roll back Ti
• Ti 00:02 < (X w00:03), reject write, roll back Ti
• Ti 00:02 >= (X r00:001 w00:01),
– write,
– set (X w00:02).

60
 Timestamping (cont’d)

• The protocol operates as follows:

▪ When Ti issues write(X)
• If TS(Ti) < Read_TS(X), reject write, roll back Ti
• If TS(Ti) < Write_TS(X), reject write
• Otherwise execute write set Write_TS(X)
▪ It means that some younger transaction with
timestamp greater TS(Ti) – and hence after Ti in the
timestamp ordering – has already read or written the
value of item X before Ti had a chance to write X thus
violating the time stamp ordering.

61
 What Do You Care About?
• When You Read?
▪ When was it last written to?
• When You Write?
▪ When was it last written to?
• Someone wrote to it after I started
▪ When was it last read?
• Somebody else is holding a copy of it

62
 Why MaxOf(Read)?

00:00 00:05 00:10

Ti00:00 read(X)

Dozens of other transactions running

• Let’s say Ti successfully reads X at 00:07 and now

needs to set the timestamp
• Should Ti set the timestamp to -00:00, 00:00, or
00:07 ?

63
 Why MaxOf(Read)? Cont’d

• If set to -00:00
▪ You lied. It was read at 00:07
• If set to 00:07
▪ You missed the point
▪ We are trying to order transactions, not individual items
(or operations)
▪ Consider the cigarettes in the supermarket example
▪ If two customers at the checkout want to buy the last
carton of cigarettes, who should get it? The one who
noticed there was only one carton left and shouts “its
mine!” (real time) or the one at the head of the lineup?
• If set to 00:00 then it’s correct because it is more
recent than -00:00.

64
 Timestamping

• In presenting schedules we shall assume that a

transaction is assigned a timestamp immediately
before its first instruction.
• “All database transactions (Read and Write) within
the same transaction must have the same time
stamp”. p. 476
• Guarantees that transactions are conflict serializable,
and the results are equivalent to a serial schedule in
which the transactions are executed in chronological
order of the timestamps.

65
 Feasible TS Schedule

T14 00:01 Set Yr to Max T15 00:02

r00:01 Set Yr to Max
read_item(Yw00:00 );
r00:02
T14 > Yw read_item(Y w00:00 ); T15 > Yw
Y:=Y-50; T15 >= Yr
r00:02
Set Xr to Max write_item(Y w00:02 ); Set Yw to T15
r00:01 );
read_item(X w00:00
T14 > Yw r00:02 Set Xr to T15
read_item(X w00:00 );
T15 > Xw
display(X + Y);
X:=X+50; T15 >= Xr
r00:02
write_item(X w00:02 ); Set Xw to T15
display(X + Y);

66
 Infeasible TS Schedule

• Supposing A is $20 and B is $8

▪ Maybe A is savings account B is current account. OK?
• T1 transfers ALL money from A to B.
▪ That is from savings to current account
▪ Outcome? A has $0. B has $28. OK?
• T2 withdraws ALL money from B.
▪ That is withdraw everything from current account
▪ Outcome B has $0. You have $8 (should be $28)

67
 Infeasible TS Schedule

T14 00:01 Set Ar to Max

read_item(A
r00:01
w00:00);
T15 00:02
T14 > Aw T14 >= Ar Set Br to Max
write_item(A r00:01);
w00:01 read_item(B r00:02);
w00:00
T15 >= Bw
Set Aw to T14 write_item(B r00:02 );
w00:02 Set Bw to T15

r00:02
read_item(B w00:02 );
T14 < Bw

write_item(B);

68
 INFeasible TS Schedule

T14 00:01
read_item(A $20.00 ); T15 00:02
write_item(A$20 - $20);
$0
read_item(B $8.00 );
write_item(B $0 );
read_item(B $0 );
write_item(B A$20 + B$0 );

69
 Time Stamping (last word)

• The time stamping protocol checks that T14 and T15

can be executed as if they were one after the other.
• A transaction that is rolled back by the system is
assigned a new timestamp and is restarted.

70