Your SlideShare is downloading. ×
0
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
2011 Db Concurrency
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

2011 Db Concurrency

446

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
446
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide


































  • Transcript

    • 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

    ×