Transactions and Concurrency Control Patterns - 2019

@vlad_mihalcea vladmihalcea.com@vlad_mihalcea vladmihalcea.com
Transactions and
Concurrency Control
Patterns

@vlad_mihalcea vladmihalcea.com
Hypersistence
Optimizer
About me

FlexCoin got hacked – 896 BTC – $600,000
https://web.archive.org/web/20160408190656/http://www.flexcoin.com/

Poloniex got hacked – 12.3% of BTC stolen
https://bitcointalk.org/index.php?topic=499580

Poloniex got hacked – 12.3% of BTC stolen
“The hacker discovered that if you place several
withdrawals all in practically the same instant, they
will get processed at more or less the same time.
This will result in a negative balance, but valid
insertions into the database, which then get picked up
by the withdrawal daemon.”
https://bitcointalk.org/index.php?topic=499580

Testing time
public void transfer(String fromIban, String toIban, Long transferCents) {
Long fromBalance = getBalance(fromIban);
if(fromBalance >= transferCents) {
addBalance(fromIban, (-1) * transferCents);
addBalance(toIban, transferCents);
}
}

What could go wrong?

ACID is a tool
https://www.flickr.com/photos/justinbaeder/5317820857/

Read-Modify-Write
public void transfer(String fromIban, String toIban, Long transferCents) {
Long fromBalance = getBalance(fromIban);
if(fromBalance >= transferCents) {
addBalance(fromIban, (-1) * transferCents);
addBalance(toIban, transferCents);
}
}

What went wrong?
• Reads and writes were executed in separate transactions
• Designed for serial execution
• No parallel execution testing
• ACIDRain [1]
[1]: http://www.bailis.org/papers/acidrain-sigmod2017.pdf

Jim Gray – 1981 – Transaction properties
“A transaction is a transformation of
state which has the properties of
atomicity (all or nothing), durability
(effects survive failures) and
consistency (a correct
transformation).”
http://research.microsoft.com/en-us/um/people/gray/papers/theTransactionConcept.pdf

Atomicity

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
ALTER TABLE
account
ADD CONSTRAINT
account_balance_check
CHECK (
balance >= 0
)

Durability

How about concurrency?
https://www.flickr.com/photos/thienzieyung/16077163871/

Serial execution
• No concurrency issues
• VoltDB (in-memory, single-threaded)

Serial execution

Serializability
• Interleaving concurrent transaction statements (reads and writes)
so that the outcome is equivalent to some serial execution.

Jim Gray – 1981 – Concurrency Control
“A simpler and more efficient scheme is to lock an
object when it is accessed. ... If the object is already
locked, then the requestor waits.
Multiple readers can be accommodated by
distinguishing two lock modes: one indicating update
access and another indicating read access. Read locks
are compatible while update locks are not.”
http://research.microsoft.com/en-us/um/people/gray/papers/theTransactionConcept.pdf

Lock types
Compatibility matrix Shared Lock Exclusive lock
Shared Lock Allow Prevent
Exclusive lock Prevent Prevent

2PL (Two-Phase Locking)
• 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)

Consistency models

Linearizability (Consistency in CAP Theorem)

Linearizability (CPU caching)
private volatile long balance;
public synchronized long getBalance() {
return balance;
}
public synchronized void setBalance(long balance) {
this.balance = balance;
}

Locking drawbacks
https://www.flickr.com/photos/mikecogh/34827705190/

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

Concurrency control
• Conflict avoidance
• 2PL (Two-Phase Locking)
• Conflict detection
• MVCC (Multi-Version Concurrency Control)

ACID timeline
2PL (Strict
Serializability)
MVCC
(Snapshot
Isolation)
NoSQL
(No ACID)
NewSQL
(Serializability)
1981 1984 2009 2011

MVCC (Multi-Version Concurrency Control)
• 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
• Vacuum process (like Java Garbage Collector)

Serializable – 2PL – conflict avoidance

Serializable – MVCC – conflict detection

Serializable – MVCC – conflict?

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

SQL-92 ACID
• Atomicity
• Consistency
• Isolation (Concurrency Control)
• Durability

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

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

Isolation level Dirty Read
Non-
Repeatable
Read
Phantom
Read
Uncommitted Yes Yes Yes Yes Yes Yes
Read
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
Isolation No No No No Yes No
SQL Server Isolation Levels

Non-
Repeatable
Read
Phantom
Read
Uncommitted No Yes Yes Yes Yes Yes
Read
Repeatable
Read No No No No Yes No
PostgreSQL Isolation Levels

MySQL Isolation Levels
Non-
Repeatable
Read
Phantom
Read
Uncommitted Yes Yes Yes Yes Yes Yes
Read
Repeatable
Read No No No No Yes Yes

ACID – Mainframe Era

ACID – Internet Era
• What about multi-request logical transactions?
• DB-level ACID is no longer sufficient
• Application-level transactions require application-level concurrency
control

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 {
@Id
private Long id;
private String title;
private long views;
private int likes;
}

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.

LockModeType.OPTIMISTIC_FORCE_INCREMENT

ACID timeline
ACID + 2PL
(Strict
Serializability)
ACID + MVCC
(Snapshot
Isolation)
NoSQL
(No ACID)
NewSQL
(Serializability)
1981 1984 2009 2011

MongoDB 4.0 ACID support
https://twitter.com/MongoDB/status/964169530833547265

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

Takeaways
• Concurrency testing
• Get to know how the underlying database system works
• Get to know what data anomalies can occur
• Get to know what solutions you have for those data anomalies

Thank you
• Twitter: @vlad_mihalcea
• Blog: https://vladmihalcea.com
• Courses: https://vladmihalcea.com/courses
• Book: https://vladmihalcea.com/books/high-performance-java-persistence/

Transactions and Concurrency Control Patterns - 2019

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Transactions and Concurrency Control Patterns - 2019

Similaire à Transactions and Concurrency Control Patterns - 2019 (20)

Plus de Vlad Mihalcea

Plus de Vlad Mihalcea (6)

Dernier

Dernier (20)

Transactions and Concurrency Control Patterns - 2019