index.txt 2.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150
  1. # Two War Stories
  2. ### (in which Locking appears as a primary antagonist)
  3. <div><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/></div>
  4. <div class="credit">John Melesky<br/>
  5. (PDX PUG, February 2012)</div>
  6. ---
  7. # Imagine, if you will...
  8. ---
  9. # The log
  10. SELECT * FROM definition_table WHERE defname='foobarbaz' FOR SHARE;
  11. SELECT * FROM definition_table WHERE defname='foobarbaz' FOR SHARE;
  12. SELECT * FROM definition_table WHERE defname='foobarbaz' FOR SHARE;
  13. SELECT * FROM definition_table WHERE defname='foobarbaz' FOR SHARE;
  14. SELECT * FROM definition_table WHERE defname='foobarbaz' FOR SHARE;
  15. ---
  16. # The problem
  17. ---
  18. # The problem
  19. * Even read-only locks need to write
  20. ---
  21. # The problem
  22. * Even read-only locks need to write
  23. * That write can have contention
  24. ---
  25. # The solution
  26. ---
  27. # The conclusion
  28. ---
  29. # The conclusion
  30. * Concurrency is baaad, mmkay?
  31. ---
  32. # The conclusion
  33. * Concurrency is baaad, mmkay?
  34. * MySQL had it right all along
  35. ---
  36. # Questions?
  37. ---
  38. # Now, imagine....
  39. ---
  40. # Egads! Deadlocks?
  41. ---
  42. # The culprit(s)
  43. SELECT * FROM sum_table WHERE sum_id = 1234
  44. AND sum_date BETWEEN '2011-01-01' AND '2011-01-10' FOR UPDATE;
  45. SELECT * FROM sum_table WHERE sum_id = 1234
  46. AND sum_date BETWEEN '2011-01-03' AND '2011-01-13' FOR UPDATE;
  47. ---
  48. # The problem
  49. ---
  50. # The problem
  51. * Lock acquisition is atomic
  52. ---
  53. # The problem
  54. * Lock acquisition is only atomic per-lock
  55. ---
  56. # The problem
  57. * Lock acquisition is only atomic per-lock
  58. * Locks need to be acquired in a stable order
  59. ---
  60. # The solution
  61. ---
  62. # The real problem
  63. ---
  64. # The real problem
  65. UPDATE sum_table SET last_update = now()
  66. WHERE sum_id = 1234
  67. AND sum_date BETWEEN '2011-01-01' and '2011-01-10';
  68. ---
  69. # The real solution
  70. ---
  71. # The real solution
  72. UPDATE sum_table SET last_update = now()
  73. WHERE sum_id = 1234
  74. AND sum_date BETWEEN '2011-01-01' and '2011-01-10'
  75. ORDER BY sum_id, sum_date;
  76. ---
  77. # The conclusion
  78. ---
  79. # The conclusion
  80. * Transactional atomicity is not the same as being deadlock-proof
  81. ---
  82. # The conclusion
  83. * Transactional atomicity is not the same as being deadlock-proof
  84. * MySQL had it right all along
  85. ---
  86. # The conclusion
  87. * Transactional atomicity is not the same as being deadlock-proof
  88. * [MySQL had it right all along](http://dev.mysql.com/doc/refman/5.5/en/update.html)
  89. ---
  90. # The MySQL way
  91. UPDATE t SET id = id + 1;
  92. ---
  93. # The MySQL way
  94. UPDATE t SET id = id + 1 ORDER BY id DESC;
  95. ---
  96. # Questions?
  97. ---
  98. # Thank you!