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!
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!
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)
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
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
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...
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
