transactions and concurrency control patterns

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