Transactions and Concurrency Control Patterns by Vlad Mihalcea Transactions and Concurrency Control are very of paramount importance when it comes to enterprise systems data integrity. However, this topic is very tough since you have to understand the inner workings of the database system, its concurrency control design choices (e.g. 2PL, MVCC), transaction isolation levels and locking schemes. In this presentation, I’m going to explain what data anomalies can happen depending on the transaction isolation level, with references to Oracle, SQL Server, PostgreSQL, and MySQL. I will also demonstrate that database transactions are not enough, especially for multi-request web flows. For this reason, I’m going to present multiple application-level transaction patterns based on both optimistic and pessimistic locking mechanisms. Last, I’m going to talk about Concurrency Control strategies used in the Hibernate second-level caching mechanism, which can boost performance without compromising strong consistency.

1. Transactions and
Concurrency Control
Patterns
VLAD MIHALCEA

2. @vlad_mihalcea
vladmihalcea.com

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

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

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

6. 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

7. 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);
}
}

8. Testing time
private long getBalance(final String iban) {
return doInJDBC(connection -> {
try(PreparedStatement statement = connection.prepareStatement(
"SELECT balance " +
"FROM account " +
"WHERE iban = ?")
) {
statement.setString(1, iban);
ResultSet resultSet = statement.executeQuery();
if(resultSet.next()) {
return resultSet.getLong(1);
}
}
throw new IllegalArgumentException("Can't find IBAN: " + iban);
});
}

9. Testing time
private void addBalance(final String iban, long balance) {
doInJDBC(connection -> {
try(PreparedStatement statement = connection.prepareStatement(
"UPDATE account " +
"SET balance = balance + ? " +
"WHERE iban = ?")
) {
statement.setLong(1, balance);
statement.setString(2, iban);
statement.executeUpdate();
}
});
}

10. assertEquals(10L, getBalance("Alice-123"));
assertEquals(0L, getBalance("Bob-456"));
transfer("Alice-123", "Bob-456", 5L);
assertEquals(5L, getBalance("Alice-123"));
assertEquals(5L, getBalance("Bob-456"));
transfer("Alice-123", "Bob-456", 5L);
assertEquals(0L, getBalance("Alice-123"));
assertEquals(10L, getBalance("Bob-456"));
transfer("Alice-123", "Bob-456", 5L);
assertEquals(0L, getBalance("Alice-123"));
assertEquals(10L, getBalance("Bob-456"));
Testing time – serial execution

11. Testing time – parallel execution
public void parallelExecution() {
CountDownLatch startLatch = new CountDownLatch(1);
CountDownLatch endLatch = new CountDownLatch(threadCount);
for (int i = 0; i < threadCount; i++) {
new Thread(() -> {
awaitOnLatch(startLatch);
transfer("Alice-123", "Bob-456", 5L);
endLatch.countDown();
}).start();
}
startLatch.countDown();
awaitOnLatch(endLatch);
}

12. Testing time – parallel execution
@Test
public void testParallelExecution() {
assertEquals(10L, getBalance("Alice-123"));
assertEquals(0L, getBalance("Bob-456"));
parallelExecution();
LOGGER.info("Alice's balance: {}", getBalance("Alice-123"));
LOGGER.info("Bob's balance: {}", getBalance("Bob-456"));
}

13. Testing time – parallel execution
int threadCount = 4;
Alice’s balance: -10
Bob’s balance: 20
int threadCount = 8;
Alice’s balance: -30
Bob’s balance: 40
int threadCount = 16;
Alice’s balance: -70
Bob’s balance: 80

14. Blame the database?

15. 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);
}
}

16. 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);
}
}

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

18. 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

19. Atomicity

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

21. Consistency
• Moving the database from one valid state to another.
• Constraint checks
• column types
• column length
• column nullability
• foreign key constraints
• unique key constraints

22. Consistency
ALTER TABLE
account
ADD CONSTRAINT
account_balance_check
CHECK (
balance >= 0
)

23. Durability

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

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

26. Serial execution

27. Serial execution

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

29. 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

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

31. 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)

32. Consistency models

33. Linearizability (Consistency in CAP Theorem)

34. Linearizability (Consistency in CAP Theorem)

35. Linearizability (Consistency in CAP Theorem)

36. Linearizability (Consistency in CAP Theorem)

37. Linearizability (Consistency in CAP Theorem)

38. Linearizability (CPU caching)
private volatile long balance;

39. Cost of locking

40. 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

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

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

43. MVCC (Multi-Version Concurrency Control)
• Readers don’t block writers and writers don’t block readers.
• Writers block writers to prevent Dirty Writes.

44. MVCC – Insert row (PostgreSQL)

45. MVCC – Insert row (PostgreSQL)

46. MVCC – Insert row (PostgreSQL)

47. MVCC – Delete row (PostgreSQL)

48. MVCC – Delete row (PostgreSQL)

49. MVCC – Delete row (PostgreSQL)

50. MVCC – Update row (PostgreSQL)

51. MVCC – Update row (PostgreSQL)

52. MVCC – Update row (PostgreSQL)

53. 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)

54. Serializable – 2PL – conflict avoidance

55. Serializable – 2PL – conflict avoidance

56. Serializable – 2PL – conflict avoidance

57. Serializable – MVCC – conflict detection

58. Serializable – MVCC – conflict detection

59. Serializable – MVCC – conflict detection

60. Serializable – MVCC – conflict?

61. Serializable – MVCC – conflict?

62. Serializable – MVCC – conflict?

63. 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.

64. Dirty Read

65. Dirty Read

66. Dirty Read

67. Dirty Read

68. Non-Repeatable Read

69. Non-Repeatable Read

70. Non-Repeatable Read

71. Non-Repeatable Read

72. Phantom Read

73. Phantom Read

74. Phantom Read

75. Read Skew

76. Read Skew

77. Read Skew

78. Read Skew

79. Write Skew

80. Write Skew

81. Write Skew

82. Lost Update

83. Lost Update

84. Lost Update

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

86. 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

87. 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

88. 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
Isolation No No No No Yes No
SQL Server Isolation Levels

89. 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
PostgreSQL Isolation Levels

90. 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

91. ACID – Mainframe Era

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

93. Stateless conversation lost update

94. Stateless conversation lost update

95. Stateless conversation lost update

96. Stateful conversation lost update

97. Stateful conversation lost update

98. Stateful conversation lost update

99. Version-based optimistic locking
@Version
private int version;
UPDATE post
SET
name = ‘Name’, version = 1
WHERE
id = 1 AND version = 0

100. Stateful versioned conversation

101. Stateful versioned conversation

102. Stateful versioned conversation

103. Write concerns

104. False positives

105. False positives

106. False positives

107. False positives

108. Write-based schema mapping

109. Non-overlapping writes

110. Non-overlapping writes

111. Non-overlapping writes

112. Non-overlapping writes

113. 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;
}

114. Non-overlapping writes

115. Non-overlapping writes

116. Non-overlapping writes

117. Non-overlapping writes

118. 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.

119. LockModeType.OPTIMISTIC_FORCE_INCREMENT

120. LockModeType.OPTIMISTIC_FORCE_INCREMENT

121. LockModeType.OPTIMISTIC_FORCE_INCREMENT

122. LockModeType.OPTIMISTIC_FORCE_INCREMENT

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

124. 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

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