Two people open quantity six. One edits it to seven and the other to nine. Accepting whichever save arrives last can silently erase an earlier decision.
I reproduced that competition with two local SQLite connections and synthetic data. This extends the earlier pure revision check into an experiment about where comparison and storage must occur together.
Distinguish the version read from the version stored now
The version an editor read is the starting point for their decision. The version in the database at save time indicates whether someone else has changed it. A command carries expected_version and compares it with the document read inside the transaction. A mismatch returns version_conflict without replacing the quantity.
Checking first and writing outside that transaction would leave another opportunity for a concurrent writer. I place the comparison and update within the same write boundary. The earlier import module explicitly did not implement database locking; this local experiment now tests the missing storage responsibility instead of renaming a comparison function as concurrency protection.
Start two connections from the same expected version
The test creates edits to seven and nine, both expecting version zero. Each task opens a separate SQLite connection and starts after a barrier. One obtains the write transaction and advances the version. The next reads the changed version. Assertions require exactly one success and one successful business event.
Scheduling may decide which quantity wins, so the test does not require seven to win every time. The invariant is that two different changes based on one expected version are not silently accepted together. A concurrent test should distinguish incidental ordering from the rule the implementation needs to preserve.
Conflict does not mean the draft should disappear
A rejected save does not make the second person’s quantity unimportant. A real screen should preserve that draft and let the person compare it with current stored values. Fetching a fresh version number and automatically overwriting the record would remove the purpose of reporting a conflict. I do not treat a conflict as permission for an automatic replacement.
The shared lab implements database rejection, not browser draft retention or a comparison interface. Those remain integration responsibilities. Keep the previously established distinction between local draft storage and a committed server save. The code checks in this article are not a new rendered-browser test that a user’s input remains visible.
A lock timeout differs from a version conflict
A version conflict says another change was committed. Failing to obtain a database lock within a timeout is a storage-access result. The lab sets a connection timeout but does not automatically retry lock errors indefinitely. An operational screen needs a way to check the outcome while preserving unsaved input, instead of treating every failure as the same instruction to save again.
SQLite writer serialization belongs to this local setup. Another database requires checking its conditional-update results and transaction contract. A file lock does not settle every operation across multiple servers and external providers. The reusable decision is to design comparison and writing together, not to copy one locking statement without its conditions.
Business meaning determines whether edits can be merged
Different fields are not automatically independent. One person’s note can affect a quantity, deadline or approval condition. Define which changes may be combined and which require reconfirmation under the company’s workflow. This example chooses an explicit conflict rather than an unreviewed merge.
The package tests sequential conflicts, actual two-connection competition, the quantity left in the database and the event count. It also verifies that successful storage and history agree. These are independent synthetic records, without changing a company’s operational database. Readers can use the boundary to identify what their own storage and interface still need to enforce.