transactions and concurrency control patterns
TRANSCRIPT
Transactions and Concurrency Control
Patterns
VLAD MIHALCEA
About me
• @Hibernate Developer
• vladmihalcea.com
• @vlad_mihalcea
• vladmihalcea
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
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
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
Atomicity
Atomicity
• Atomicity requires rolling back
• Rolling back requires preventing dirty writes
Dirty Write Anomaly
Consistency
• Moving the database from one valid state to another.
• Constraint checks
• column types
• column length
• column nullability
• foreign key constraints
• unique key constraints
Consistency in CAP – Linearizability
Durability
• Durability ensures that all committed transaction changes become permanent.
Durability
SQL-92 ACID
• Atomicity
• Consistency
• Isolation
• Durability
Serializability
• Interleaving concurrent transaction statements so that the outcome is equivalent to a serial execution
Serial execution
Conflict
Dealing with Concurrency
• Avoid it• VoltDB (in-memory, single-threaded, guarantees Serializability)
• Control it• RDBMS (Concurrency Control and isolation levels)
Dealing with conflicts in RDBMS
• Conflict avoidance• 2PL (Two-Phase Locking)
• Conflict detection• MVCC (Multi-Version Concurrency Control)
Lock types
Compatibility matrix Shared Lock Exclusive lock
Shared Lock Allow Prevent
Exclusive lock Prevent Prevent
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)
Cost of locking
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
MVCC
• Readers don’t block writers and writers don’t block readers.
• Writers block writers to prevent Dirty Writes.
MVCC – Insert row (PostgreSQL)
MVCC – Delete row (PostgreSQL)
MVCC – Update row (PostgreSQL)
MVCC
• Two types of snapshots:• Query-level: Read Committed
• Transaction-level: Snapshot Isolation
• Watch out for long-running transactions
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.
Dirty Read
Non-Repeatable Read
Phantom Read
Read Skew
Write Skew
Lost Update
2PL – Phantom Read
MVCC – Phantom Read
MVCC – Phantom Read?
SQL Standard Isolation Levels
Isolation Level Dirty Read
Non-Repeatable Read
Phantom Read
Read Uncommitted Yes Yes YesRead Committed No Yes YesRepeatable Read No No Yes
Serializable No No No
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
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 YesRead Committed No Yes Yes Yes Yes YesRepeatable Read No No Yes No No No
Serializable No No No No No NoRead Committed SI No Yes Yes Yes Yes YesSnapshot Ioslation No No No No Yes No
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 YesRead Committed No Yes Yes Yes Yes YesRepeatable Read No No No No Yes No
Serializable No No No No No No
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 YesRead Committed No Yes Yes Yes Yes YesRepeatable Read No No No No Yes Yes
Serializable No No No No No No
Beyond ACID
• ACID is not sufficient
• What about multi-request logical transactions?
Stateless conversation lost update
Stateful conversation lost update
Version-based optimistic locking
@Version
private int version;
UPDATE post
SET
name = ‘Name’, version = 1
WHERE
id = 1 AND version = 0
Stateful versioned conversation
Write concerns
False positives
Write-based schema mapping
Non-overlapping writes
Versionless optimistic locking
@Entity @Table(name = "post") @DynamicUpdate@OptimisticLocking(type = OptimisticLockType.DIRTY)public class Post {
@Idprivate Long id;
private String title;
private long views;
private int likes;}
Non-overlapping writes
Explicit optimistic locking modesLock Mode Type Description
NONE In the absence of explicit locking, the application will use implicit locking (optimistic or pessimistic)
OPTIMISTICAlways issues a version check upon transaction commit, therefore ensuring optimistic locking repeatable reads.
READ Same as OPTIMISTIC.
OPTIMISTIC_FORCE_INCREMENTAlways 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_READA shared lock is acquired to prevent any other transaction from acquiring a PESSIMISTIC_WRITE lock.
PESSIMISTIC_WRITEAn exclusive lock is acquired to prevent any other transaction from acquiring a PESSIMISTIC_READ or a PESSIMISTIC_WRITE lock.
PESSIMISTIC_FORCE_INCREMENTA 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.
LockModeType.OPTIMISTIC_FORCE_INCREMENT
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);
LockModeType.OPTIMISTIC_FORCE_INCREMENT
Thank you
Questions and Answers