2011 Db Concurrency

426 views
396 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
426
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide


































  • 2011 Db Concurrency

    1. 1. Concurrent Transactions Alan Medlar amedlar@cs.ucl.ac.uk
    2. 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. 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. 4. Schedules • Concerned with the order of execution • Consider two transactions, T and T : 1 2
    5. 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. 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. 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. 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. 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. 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. 11. Conflict Analysis • What went wrong in the example? • Ordering of reads and writes caused an inconsistency
    12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. Serializability • Paramount correctness criteria for concurrent database transactions • Ensures isolation between transactions • Ensures consistency despite other transactions
    24. 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. 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. 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. 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. 28. Problem: Immediate Modification • If during a transaction our database uses immediate modification we have a problem, transactions are not isolated!
    29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Next: Distributed Transactions

    ×