Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Transactions and Concurrency Control Patterns

1,813 views

Published on

30 years of RDBMS and this topic is pretty much "uncharted territory" for the vast majority of back-end developers.

This talk is relevant because data integrity is very important for many enterprise applications. At the end of this talk, the audience will get a better picture of the strengths and limitations of database systems concurrency control mechanisms.

Published in: Internet
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Transactions and Concurrency Control Patterns

  1. 1. Transactions and Concurrency Control Patterns VLAD MIHALCEA
  2. 2. About me • @Hibernate Developer • vladmihalcea.com • @vlad_mihalcea • vladmihalcea
  3. 3. Google Developers “We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.” Spanner: Google’s Globally-Distributed Database - https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
  4. 4. Database transactions • Every statement is executed in the context of a transaction • There are two types of transactions: • Implicit – auto-commit • Explicit – BEGIN, COMMIT or ROLLBACK
  5. 5. History of ACID In SQL-86, there were only three transaction properties: • Consistency • Atomicity • Durability The Transaction Concept: Virtues and Limitations http://research.microsoft.com/en-us/um/people/gray/papers/theTransactionConcept.pdf
  6. 6. Atomicity
  7. 7. Atomicity • Atomicity requires rolling back • Rolling back requires preventing dirty writes
  8. 8. Dirty Write Anomaly
  9. 9. Consistency • Moving the database from one valid state to another. • Constraint checks • column types • column length • column nullability • foreign key constraints • unique key constraints
  10. 10. Consistency in CAP – Linearizability
  11. 11. Durability • Durability ensures that all committed transaction changes become permanent.
  12. 12. Durability
  13. 13. SQL-92 ACID • Atomicity • Consistency • Isolation • Durability
  14. 14. Serializability • Interleaving concurrent transaction statements so that the outcome is equivalent to a serial execution
  15. 15. Serial execution
  16. 16. Conflict
  17. 17. Dealing with Concurrency • Avoid it • VoltDB (in-memory, single-threaded, guarantees Serializability) • Control it • RDBMS (Concurrency Control and isolation levels)
  18. 18. Dealing with conflicts in RDBMS • Conflict avoidance • 2PL (Two-Phase Locking) • Conflict detection • MVCC (Multi-Version Concurrency Control)
  19. 19. Lock types Compatibility matrix Shared Lock Exclusive lock Shared Lock Allow Prevent Exclusive lock Prevent Prevent
  20. 20. 2PL • Simple to reason about: • Reads acquire shared locks • Writes acquire exclusive locks • The 2PL protocol: • expanding phase (acquire locks, release no lock) • shrinking phase (release all locks, no further lock acquisition)
  21. 21. Cost of locking
  22. 22. Challenges have changed “At present [1981], the largest airlines and banks have about 10,000 terminals and about 100 active transactions at any instant. These transactions live for a second or two and are gone forever.” The Transaction Concept: Virtues and Limitations - http://research.microsoft.com/en-us/um/people/gray/papers/theTransactionConcept.pdf
  23. 23. MVCC • Readers don’t block writers and writers don’t block readers. • Writers block writers to prevent Dirty Writes.
  24. 24. MVCC – Insert row (PostgreSQL)
  25. 25. MVCC – Delete row (PostgreSQL)
  26. 26. MVCC – Update row (PostgreSQL)
  27. 27. MVCC • Two types of snapshots: • Query-level: Read Committed • Transaction-level: Snapshot Isolation • Watch out for long-running transactions
  28. 28. Phenomena • The SQL-92 standard introduced three phenomena: • dirty read • non-repeatable read • phantom read. • In reality, there are more: • dirty write • read skew • write skew • lost update.
  29. 29. Dirty Read
  30. 30. Non-Repeatable Read
  31. 31. Phantom Read
  32. 32. Read Skew
  33. 33. Write Skew
  34. 34. Lost Update
  35. 35. 2PL – Phantom Read
  36. 36. MVCC – Phantom Read
  37. 37. MVCC – Phantom Read?
  38. 38. SQL Standard Isolation Levels Isolation Level Dirty Read Non- Repeatable Read Phantom Read Read Uncommitted Yes Yes Yes Read Committed No Yes Yes Repeatable Read No No Yes Serializable No No No
  39. 39. Oracle Isolation Levels Isolation Level Dirty Read Non- Repeatable Read Phantom Read Read Skew Write Skew Lost Update Read Committed No Yes Yes Yes Yes Yes Serializable No No No No Yes No
  40. 40. SQL Server Isolation Levels Isolation level Dirty Read Non- Repeatable Read Phantom Read Read Skew Write Skew Lost Update Read Uncommitted Yes Yes Yes Yes Yes Yes Read Committed No Yes Yes Yes Yes Yes Repeatable Read No No Yes No No No Serializable No No No No No No Read Committed SI No Yes Yes Yes Yes Yes Snapshot Ioslation No No No No Yes No
  41. 41. PostgreSQL Isolation Levels Isolation level Dirty Read Non- Repeatable Read Phantom Read Read Skew Write Skew Lost Update Read Uncommitted No Yes Yes Yes Yes Yes Read Committed No Yes Yes Yes Yes Yes Repeatable Read No No No No Yes No Serializable No No No No No No
  42. 42. MySQL Isolation Levels Isolation level Dirty Read Non- Repeatable Read Phantom Read Read Skew Write Skew Lost Update Read Uncommitted Yes Yes Yes Yes Yes Yes Read Committed No Yes Yes Yes Yes Yes Repeatable Read No No No No Yes Yes Serializable No No No No No No
  43. 43. Beyond ACID • ACID is not sufficient • What about multi-request logical transactions?
  44. 44. Stateless conversation lost update
  45. 45. Stateful conversation lost update
  46. 46. Version-based optimistic locking @Version private int version; UPDATE post SET name = ‘Name’, version = 1 WHERE id = 1 AND version = 0
  47. 47. Stateful versioned conversation
  48. 48. Write concerns
  49. 49. False positives
  50. 50. Write-based schema mapping
  51. 51. Non-overlapping writes
  52. 52. Versionless optimistic locking @Entity @Table(name = "post") @DynamicUpdate @OptimisticLocking(type = OptimisticLockType.DIRTY) public class Post { @Id private Long id; private String title; private long views; private int likes; }
  53. 53. Non-overlapping writes
  54. 54. Explicit optimistic locking modes Lock Mode Type Description NONE In the absence of explicit locking, the application will use implicit locking (optimistic or pessimistic) OPTIMISTIC Always issues a version check upon transaction commit, therefore ensuring optimistic locking repeatable reads. READ Same as OPTIMISTIC. OPTIMISTIC_FORCE_INCREMENT Always increases the entity version (even when the entity doesn’t change) and issues a version check upon transaction commit, therefore ensuring optimistic locking repeatable reads. WRITE Same as OPTIMISTIC_FORCE_INCREMENT. PESSIMISTIC_READ A shared lock is acquired to prevent any other transaction from acquiring a PESSIMISTIC_WRITE lock. PESSIMISTIC_WRITE An exclusive lock is acquired to prevent any other transaction from acquiring a PESSIMISTIC_READ or a PESSIMISTIC_WRITE lock. PESSIMISTIC_FORCE_INCREMENT A database lock is acquired to prevent any other transaction from acquiring a PESSIMISTIC_READ or a PESSIMISTIC_WRITE lock and the entity version is incremented upon transaction commit.
  55. 55. LockModeType.OPTIMISTIC_FORCE_INCREMENT
  56. 56. LockModeType.OPTIMISTIC_FORCE_INCREMENT Repository repository = entityManager.find(Repository.class, 1L, LockModeType.OPTIMISTIC_FORCE_INCREMENT); executeSync(() -> { doInJPA(_entityManager -> { Repository _repository = _entityManager.find(Repository.class, 1L, LockModeType.OPTIMISTIC_FORCE_INCREMENT); Commit _commit = new Commit(_repository); _commit.getChanges().add(new Change("Intro.md", "0a1,2...")); _entityManager.persist(_commit); }); }); Commit commit = new Commit(repository); commit.getChanges().add(new Change("FrontMatter.md", "0a1,5...")); commit.getChanges().add(new Change("HibernateIntro.md", "17c17...")); entityManager.persist(commit);
  57. 57. LockModeType.OPTIMISTIC_FORCE_INCREMENT
  58. 58. Thank you Questions and Answers

×