This document discusses concurrent database transactions and ensuring consistency when multiple transactions access the same data concurrently. It introduces the concept of conflict analysis to identify issues that can cause inconsistencies. Various techniques are discussed to enforce serializability, such as locking and two-phase locking, which allow concurrent transactions while maintaining consistency through an ordering equivalent to a serial schedule.

1. Concurrent Transactions
Alan Medlar
amedlar@cs.ucl.ac.uk

2. Concurrent Transactions
• We want our database to be accessible to
many clients concurrently
• Multiple processors or cores accessing
same storage (containing whole database)
• Multiple processors distributed over a
network each with local storage (each
holding a portion of the database)

3. Concurrent Transactions
• To increase performance we want to allow
multiple database transactions, being
processed on separate processors, to take
place at once
• Run into problems when two (or more) of
these transactions want to access the same
data!

4. Schedules
• Concerned with the order of execution
• Consider two transactions, T and T :
1 2

5. T1 T2 T1 T2
read(X) read(X)
X = X-100 tmp = X*0.1
write(X) X=X-tmp
read(Y) write(X)
Y = Y+100 read(Y)
write(Y) Y=Y+tmp
read(X) write(Y)
tmp = X*0.1 read(X)
X=X-tmp X = X-100
write(X) write(X)
read(Y) read(Y)
Y=Y+tmp Y = Y+100
write(Y) write(Y)

6. Schedules
• Schedules of T and T2 are serial due to
1
one transaction finishing before the other
• If Tand T2 were to happen at the same
1
time, forcing serialisation would limit
performance!

7. T1 T2
read(X)
X = X-100
write(X)
read(X)
tmp = X*0.1
X=X-tmp
write(X)
read(Y)
Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

8. T1 T2
read(X)
X = X-100
write(X)
Despite these read(X)
transactions not tmp = X*0.1
being serialised, the X=X-tmp
schedule ensures the write(X)
resulting database is read(Y)
consistent Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

9. T1 T2
read(X)
X = X-100
read(X)
tmp = X*0.1
X=X-tmp
write(X)
write(X)
read(Y)
Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

10. T1 T2
read(X)
X = X-100
read(X)
Here the database
tmp = X*0.1
gets into an
X=X-tmp
inconsistent state
write(X)
because the write(X)
write(X)
of T2 is lost due to
read(Y)
being overwritten by
Y = Y+100
T1!
write(Y)
read(Y)
Y=Y+tmp
write(Y)

11. Conflict Analysis
• What went wrong in the example?
• Ordering of reads and writes caused an inconsistency

12. Conflict Analysis
• What went wrong in the example?
• Ordering of reads and writes caused an inconsistency
• Use conflict analysis to identify the cause of the
problem...
• Intuition: reads and writes applied in the same order as
a serial schedule will always result in a consistent state
• Examine the schedule and try to rearrange them into
the same order as a serial schedule by swapping
instructions (paying special attention to “conflicts”)

13. Conflicts
• Looking consecutive reads and writes:
• If they access different data items, they can
be applied in any order
• If they access the same data items, then
the order of operations may be
important, i.e. they may conflict

14. Conflicts
• Looking consecutive reads and writes:
• If they access different data items, they can
be applied in any order
• If they access the same data items, then
the order of operations may be
important, i.e. they may conflict
• (This is simplified! We are not considering
insertion and deletion)

15. Conflict Rules
• In a schedule (only reads and writes) for consecutive
instructions i1 and i2 :
• i1 = read(x), i2 = read(x) : no conflict
• i1 = read(x), i2 = write(x) : conflict
(ordering dictates whether i1 gets value of write or
previous state)
• i1 = write(x), i2 = read(x) : conflict
• i1 = write(x), i2 = write(x) : conflict
(writes do not affect one another, but will affect next
read)

16. Conflict Serialization
• If a schedule S is transformed into schedule S’
by a series of non-conflicting instruction
swaps, the S and S’ are conflict equivalent
• A schedule is conflict serializable if it is conflict
equivalent to a serial schedule
• A schedule that is conflict serializable will
produce the same final state as some serial
schedule and will leave the database in a
consistent state

17. T1 T2
read(X)
X = X-100
write(X)
read(X)
tmp = X*0.1
X=X-tmp
write(X)
read(Y)
Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

18. T1 T2
read(X)
X = X-100
write(X)
read(X)
tmp = X*0.1
X=X-tmp
write(X)
read(Y)
Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

19. T1 T2
read(X)
X = X-100
write(X)
read(X)
tmp = X*0.1
X=X-tmp
write(X)
read(Y)
Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

20. T1 T2 T1 T2
read(X) read(X)
X = X-100 X = X-100
write(X) write(X)
read(X) read(Y)
tmp = X*0.1 Y = Y+100
X=X-tmp write(Y)
write(X) read(X)
read(Y) tmp = X*0.1
Y = Y+100 X=X-tmp
write(Y) write(X)
read(Y) read(Y)
Y=Y+tmp Y=Y+tmp
write(Y) write(Y)

21. T1 T2
read(X)
X = X-100
read(X)
tmp = X*0.1
X=X-tmp
write(X)
write(X)
read(Y)
Y = Y+100
write(Y)
read(Y)
Y=Y+tmp
write(Y)

22. T1 T2
read(X)
X = X-100
read(X)
These instructions
tmp = X*0.1
cannot be swapped
X=X-tmp
because they are in
write(X)
conflict!
write(X)
This schedule cannot read(Y)
be re-ordered into a Y = Y+100
serial schedule... write(Y)
read(Y)
Y=Y+tmp
write(Y)

23. Serializability
• Paramount correctness criteria for
concurrent database transactions
• Ensures isolation between transactions
• Ensures consistency despite other
transactions

24. Locking
• We can get a serialisable schedule by
enforcing mutual exclusion on data items: this
could be achieved using simple locking
• shared lock - to read data items, can only
be granted if there are either no locks or
only shared locks on a data item
• write lock - for writing, can only be granted
if there are no other locks on the data item

25. T1 T2
write_lock(X)
read(X)
X = X-100
write(X)
unlock(X)
write_lock(X)
read(X)
tmp = X*0.1
X=X-tmp
write(X)
unlock(X)
write_lock(Y)
read(Y)
Y = Y+100
write(Y)
unlock(Y)
write_lock(Y)
read(Y)
Y=Y+tmp
write(Y)
unlock(Y)

26. T1 T2 T1 T2
write_lock(X) write_lock(X)
read(X) read(X)
X = X-100 X = X-100
write(X) write_lock(X)
unlock(X) read(X)
write_lock(X) tmp = X*0.1
read(X) X=X-tmp
tmp = X*0.1 write(X)
X=X-tmp unlock(X)
write(X) write(X)
unlock(X) unlock(X)
write_lock(Y) write_lock(Y)
read(Y) read(Y)
Y = Y+100 Y = Y+100
write(Y) write(Y)
unlock(Y) unlock(Y)
write_lock(Y) write_lock(Y)
read(Y) read(Y)
Y=Y+tmp Y=Y+tmp
write(Y) write(Y)
unlock(Y) unlock(Y)

27. T1 T2 T1 T2
write_lock(X) write_lock(X)
read(X) read(X)
X = X-100 X = X-100
write(X) write_lock(X)
s!
unlock(X) read(X)
ail
f
write_lock(X) tmp = X*0.1
k
oc
read(X) X=X-tmp
l
tmp = X*0.1 write(X)
X=X-tmp unlock(X)
write(X) write(X)
unlock(X) unlock(X)
write_lock(Y) write_lock(Y)
read(Y) read(Y)
Y = Y+100 Y = Y+100
write(Y) write(Y)
unlock(Y) unlock(Y)
write_lock(Y) write_lock(Y)
read(Y) read(Y)
Y=Y+tmp Y=Y+tmp
write(Y) write(Y)
unlock(Y) unlock(Y)

28. Problem: Immediate Modification
• If during a transaction our database uses
immediate modification we have a
problem, transactions are not isolated!

29. T1 T2
write-lock(P)
read(P)
P = P - 100
write(P)
unlock(P)
read-lock(P)
read(P)
unlock(P)
read-lock(Q)
read(Q)
unlock(Q)
printf(“%dn”, P + Q)
write-lock(Q)
read(Q)
Q = Q + 100
write(Q)
unlock(Q)

30. T1 T2
}
P = 100
150
write-lock(P)
Q = 50
read(P)
P = P - 100
write(P)
unlock(P)
read-lock(P)
read(P)
unlock(P)
read-lock(Q)
read(Q)
unlock(Q)
printf(“%dn”, P + Q)
write-lock(Q)
read(Q)
Q = Q + 100
write(Q)
unlock(Q)

31. T1 T2
}
P = 100
150
write-lock(P)
Q = 50
read(P)
P = P - 100
write(P)
}
P= 0
50
unlock(P)
Q = 50
read-lock(P)
read(P)
unlock(P)
read-lock(Q)
read(Q)
unlock(Q)
printf(“%dn”, P + Q)
write-lock(Q)
read(Q)
Q = Q + 100
write(Q)
unlock(Q)

32. T1 T2
}
P = 100
150
write-lock(P)
Q = 50
read(P)
P = P - 100
write(P)
}
P= 0
50
unlock(P)
Q = 50
read-lock(P)
read(P)
unlock(P)
read-lock(Q)
read(Q)
unlock(Q)
printf(“%dn”, P + Q)
write-lock(Q)
read(Q)
Q = Q + 100
write(Q)
}
P= 0
150
unlock(Q)
Q = 150

33. T1 T2
write-lock(P)
read(P)
P = P - 100
Solution: release locks
write(P)
as late as possible!
write-lock(Q)
read(Q)
(ensures serial schedule,
Q = Q + 100
but potential deadlocks!)
write(Q)
unlock(Q)
unlock(P)
read-lock(P)
read(P)
read-lock(Q)
read(Q)
unlock(Q)
unlock(P)
printf(“%dn”, P + Q)

34. 2-Phase Locking
• One of many methods to ensure serializability
• Growth phase: transactions can only acquire
locks
• Shrinking phase: transactions can only release
locks
• Once a transaction has started to release locks
it cannot acquire anymore...

35. T1 T2
T1 Growth Phase write-lock(P)
read(P)
P = P - 100
write(P)
write-lock(Q)
read(Q)
Q = Q + 100
write(Q)
T1 Shrinking Phase unlock(Q)
unlock(P)
T2 Growth Phase
read-lock(P)
read(P)
read-lock(Q)
read(Q)
T2 Shrinking Phase
unlock(Q)
unlock(P)
printf(“%dn”, P + Q)

36. Deadlock
• Two or more transactions are waiting for
locks that the other holds, hence none of
those involved make progress
• Dealt with in different ways, not covered in
this course...

37. Summary
• Most concurrent transactions have no
conflicts: they either all access different
data items or else only perform reads
• For the transactions that might conflict we
can enforce serializability to maintain the
ACID properties

38. Next: Distributed Transactions