Race condition

Q: How deeply does Java Persistence with Spring Data and Hibernate epub cover race condition?

Works through the bid transaction and its failed commit, including why ordinary Item versioning misses the conflict.

As explained in Java Persistence with Spring Data and Hibernate epub

A race condition is a correctness problem in which the outcome depends on the timing or interleaving of concurrent operations.

A race condition can arise when accepting an auction bid. The application reads the highest bid, checks that a new bid is higher, then stores it. Another transaction may place a bid between the read and the insert, leaving the comparison based on stale data. section 11.2.2

Versioning the Item alone does not detect this conflict: inserting a separate Bid does not modify the Item. Use JPA’s OPTIMISTIC_FORCE_INCREMENT lock mode on the Item when reading it. The forced version change makes a concurrent conflict detectable at commit. If bids instead belong to an Item @ElementCollection, adding one increments the Item version without a forced increment. section 11.2.2

Listing 11.5 Forcing a version increment of an entity instance

Path: /Ch11/transactions/src/test/java/com/manning/javapersistence/ch11
 /concurrency/Versioning.java – forceIncrement()
 
   EntityManager em = emf.createEntityManager();
   em.getTransaction().begin();
Item item = em.find(                                          #1
    Item.class,
    ITEM_ID,
    LockModeType.OPTIMISTIC_FORCE_INCREMENT
);
Bid highestBid = queryHighestBid(em, item);
// . . .  Another transaction changes the record
Bid newBid = new Bid(
        new BigDecimal("45.45"),
        item,
        highestBid);
em.persist(newBid);                                           #2
assertThrows(RollbackException.class,
                   () -> em.getTransaction().commit());       #3
em.close();
#1 <kbd>find()</kbd> accepts a <kbd>LockModeType</kbd>. The <kbd>OPTIMISTIC_FORCE_INCREMENT</kbd> mode tells Hibernate that the version of the retrieved <kbd>Item</kbd> should be incremented after loading, even if it’s never modified in the unit of work.
#2 The code persists a new <kbd>Bid</kbd> instance; this doesn’t affect any values of the <kbd>Item</kbd> instance. A new row is inserted into the <kbd>BID</kbd> table. Hibernate wouldn’t detect concurrently made bids without a forced version increment of the <kbd>Item</kbd>.
#3 When flushing the persistence context, Hibernate executes an <kbd>INSERT</kbd> for the new <kbd>Bid</kbd> and forces an <kbd>UPDATE</kbd> of the <kbd>Item</kbd> with a version check. If someone modified the <kbd>Item</kbd> concurrently or placed a <kbd>Bid</kbd> concurrently with this procedure, Hibernate throws an exception.

The transaction loads an Item with OPTIMISTIC_FORCE_INCREMENT, reads its highest bid, persists a new Bid, and demonstrates a failed commit after another transaction changes the record. section 11.2.2

How Java Persistence with Spring Data and Hibernate epub covers it

Cover of Java Persistence with Spring Data and Hibernate epub

liveBook manning.com

Read Java Persistence with Spring Data and Hibernate epub on liveBook Get the book at manning.com

Also explained in

liveBook manning.com

C++ Concurrency in Action, Second EditionA race condition is a program condition in which behavior depends on the timing or ordering of operations performed by concurrent threads.
liveBook manning.com

Learn Concurrent Programming with GoA race condition is a concurrency defect in which program behavior depends on the timing or interleaving of unsynchronized operations.
liveBook manning.com

Learn Go with Pocket-Sized ProjectsA race condition is a correctness fault in which the result depends on the timing or interleaving of concurrent operations.
liveBook manning.com

Python Concurrency with asyncioA race condition is a concurrency bug in which the result or observable behavior depends on the timing or ordering of concurrent operations.
liveBook manning.com

Functional Design and Architecture: Examples in HaskellA race condition is a concurrency defect in which the outcome depends on an unexpected competition between threads for a shared resource.
liveBook manning.com

Grokking ConcurrencyA race condition is a concurrency bug in which the result depends on the timing or ordering of competing accesses to shared state or resources.
liveBook manning.com

Troubleshooting Java, Second EditionA race condition is a concurrency defect whose outcome depends on the timing or interleaving of operations.
liveBook manning.com

Advanced Algorithms and Data StructuresA race condition is a concurrency error in which program behavior depends on the timing or interleaving of operations.
liveBook manning.com

Functional Programming in Scala, Second EditionA race condition is a concurrency defect in which a result depends on the timing or interleaving of operations from multiple threads.
liveBook manning.com

C# Concurrency: Asynchronous and multithreaded programmingA race condition is a concurrent-execution defect in which program results depend on uncontrollable timing or interleaving between execution flows.
liveBook manning.com

Go by ExampleA race condition is a concurrency defect in which program behavior depends on the timing or ordering of operations accessing shared state.
liveBook manning.com

Modern C, Third EditionA race condition is an execution condition in which the result depends on the relative timing or interleaving of accesses by concurrent or asynchronously executing code.
liveBook manning.com

React Hooks in Action: With Suspense and Concurrent ModeA race condition is a correctness problem in which the result depends on the timing or ordering of concurrent operations.
liveBook manning.com

100 Go Mistakes and How to Avoid ThemA race condition is a concurrency defect in which program behavior depends on the timing or ordering of operations on shared state.
liveBook manning.com

Think Distributed SystemsA concurrency situation in which at least one possible ordering of actions produces an incorrect result.
liveBook manning.com

Rust Servers, Services, and AppsA race condition is a concurrency defect in which the result depends on the timing or interleaving of operations.
liveBook manning.com

Object-Oriented Software Design in C++A race condition is a concurrency defect in which program behavior depends on the timing or ordering of simultaneous operations.
liveBook manning.com

Go in Practice, Second EditionA race condition is a correctness or timing defect caused by program behavior depending on the uncontrolled ordering of concurrent operations.
liveBook manning.com

F# in Action: A Revised Edition of Get Programming with F#A race condition is a concurrency defect in which a result depends on the timing or interleaving of competing operations.

Compare how 20 books explain race condition →

Related concepts

lockingaddressed by · Locking is a synchronization technique that restricts concurrent access to shared resources or protected operations.
data raceincludes · A data race is a concurrent access to shared data in which at least one access is a write and the accesses are not adequately synchronized.
deadlockcontrasts with · A deadlock is a state in concurrent execution where two or more activities are indefinitely blocked by dependencies on resources, events, or progress that cannot become available.
go testmeasured by · go test is the Go command that builds and runs tests for specified packages and can also execute benchmarks and report coverage.
double-checked locking patternproduced by · Double-checked locking is a synchronization pattern that checks a shared pointer before and after acquiring a lock to avoid locking when initialization is complete.
read-modify-write operationproduced by · An operation that reads a value from a location, computes or selects an update, and writes the resulting value back to that location.

This explainer was generated by Manning's knowledge graph from the text of Java Persistence with Spring Data and Hibernate epub. The section links point to the parts of the book it draws on.