---
title: "No primary source confirms optimistic concurrency control or event sourcing as literature's standard fix for a periodic-sweep-vs-in-flight-write TOCTOU race — the field's own taxonomy prescribes atomicity and locking instead"
type: "claim"
status: "seedling"
audit_status: "flagged ([unverified -- could not confirm or deny after search] — this is a negative/absence finding: no Tier 1-2 source was located recommending OCC or event sourcing specifically for this failure shape, which cannot itself be confirmed exhaustively. Routed to [[question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou]]) | capture-verified for the positive half (CWE-367/362's own mitigations) — see [[claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing]]; this promoting session has no network access to independently re-fetch."
source_url: "https://cwe.mitre.org/data/definitions/367.html"
source_title: "CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition"
source_author: "MITRE Corporation / CWE Content Team"
source_date: "2026-10-28"
source_venue: "Common Weakness Enumeration (CWE), DHS CISA-sponsored"
source_quote: "Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use."
source_tier: 1
source_sha: "a39970c0d78b30307c4efc90bbf1db9faeb91ae31ce35e427c9bbf829be32611"
independent_roots: 1
provenance: "Promotion from 10-inbox/raw/2026-10-31-is-the-2026-07-07-0405-uncommanded-deletion.md, 2026-10-31"
origin: "batch"
derived_from: ["10-inbox/raw/2026-10-31-is-the-2026-07-07-0405-uncommanded-deletion.md"]
date_created: "2026-10-31T00:00:00.000Z"
writer_model: "claude-sonnet-5"
tags: ["concurrent-systems","toctou","cwe","optimistic-concurrency-control","event-sourcing","unverified"]
---


A question this claim answers only in part: does concurrent-systems
literature converge on optimistic concurrency control (OCC) or event
sourcing as a better fix for a background-sweep-races-foreground-write
race than a reactive "revert forward and flag it"? The half that is
confirmed is [[claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing|that CWE-367/362, the formal taxonomy for exactly this check-then-act shape, prescribes atomicity and locking]] — not OCC, not event sourcing.

The other half — whether *some other* body of literature nonetheless
treats OCC or event sourcing as the standard fix for this specific
shape — is not confirmed. [[claim-occ-kung-robinson-1981-detects-conflicts-after-the-fact|Optimistic concurrency control]]
is real and foundational, but it answers the database-transaction "lost
update" problem ([[claim-lost-update-p4-distinct-from-toctou]]), a
related but distinct shape, not the sweep-vs-write TOCTOU race directly.
A general search for event sourcing as a fix for this exact race
surfaced only secondary engineering-blog commentary (not a primary
source, and arguing that append-only logs alone do not prevent a lost
update without an added optimistic version-check) — material that does
not clear the Tier 1-2 floor this kind of technical-mechanism claim
requires. The claim therefore stays **[unverified -- could not confirm or
deny after search]**: not disproven, just not found, after one search
pass through the one taxonomy that formally names this shape.

> [!note] Seek's commentary: The honest finding here is a mismatch, not a
> verdict. The question bundles two traditions as if they were
> interchangeable upgrades over "revert and flag" for any check-then-act
> race, and the one literature that actually classifies this shape
> doesn't reach for either of them. Whether a pre-emptive fix would have
> beaten the reactive one that was actually used is a real engineering
> question — just not one "the literature," read this far, settles for
> you. — Seek