Transactions and Concurrency Control Patterns Overview
•
7 likes•2,716 views
This document discusses transactions and concurrency control patterns. It begins by providing background on transactions, including the history and definitions of ACID properties. It then covers topics like locking, multi-version concurrency control, isolation levels, and phenomena that can occur with concurrent transactions like dirty reads, non-repeatable reads and phantom reads. The document also discusses challenges that have emerged with large-scale systems and patterns beyond traditional ACID properties to handle things like logical transactions and state management across multiple requests.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (20)
Similar to Transactions and Concurrency Control Patterns Overview
Similar to Transactions and Concurrency Control Patterns Overview (20)
Recently uploaded
Recently uploaded (20)
Transactions and Concurrency Control Patterns Overview
- 2. About me • @Hibernate Developer • vladmihalcea.com • @vlad_mihalcea • vladmihalcea
- 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. 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. 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. Atomicity
- 7. Atomicity • Atomicity requires rolling back • Rolling back requires preventing dirty writes
- 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. Consistency in CAP – Linearizability
- 11. Durability • Durability ensures that all committed transaction changes become permanent.
- 12. Durability
- 13. SQL-92 ACID • Atomicity • Consistency • Isolation • Durability
- 14. Serializability • Interleaving concurrent transaction statements so that the outcome is equivalent to a serial execution
- 15. Serial execution
- 16. Conflict
- 17. Dealing with Concurrency • Avoid it • VoltDB (in-memory, single-threaded, guarantees Serializability) • Control it • RDBMS (Concurrency Control and isolation levels)
- 18. Dealing with conflicts in RDBMS • Conflict avoidance • 2PL (Two-Phase Locking) • Conflict detection • MVCC (Multi-Version Concurrency Control)
- 19. Lock types Compatibility matrix Shared Lock Exclusive lock Shared Lock Allow Prevent Exclusive lock Prevent Prevent
- 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. Cost of locking
- 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. MVCC • Readers don’t block writers and writers don’t block readers. • Writers block writers to prevent Dirty Writes.
- 24. MVCC – Insert row (PostgreSQL)
- 25. MVCC – Delete row (PostgreSQL)
- 26. MVCC – Update row (PostgreSQL)
- 27. MVCC • Two types of snapshots: • Query-level: Read Committed • Transaction-level: Snapshot Isolation • Watch out for long-running transactions
- 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. Dirty Read
- 31. Phantom Read
- 32. Read Skew
- 33. Write Skew
- 34. Lost Update
- 35. 2PL – Phantom Read
- 36. MVCC – Phantom Read
- 37. MVCC – Phantom Read?
- 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. 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. 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. 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. 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. Beyond ACID • ACID is not sufficient • What about multi-request logical transactions?
- 44. Stateless conversation lost update
- 45. Stateful conversation lost update
- 46. Version-based optimistic locking @Version private int version; UPDATE post SET name = ‘Name’, version = 1 WHERE id = 1 AND version = 0
- 48. Write concerns
- 49. False positives
- 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; }
- 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.
- 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);
- 58. Thank you Questions and Answers