Transactional Precondition Guard¶
Transaction-boundary guard — instantiates Use-Time Referent Validation
Runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing.
The gap between "I checked it" and "I used it" is where concurrent actors do their damage. Transactional Precondition Guard removes the gap: it wraps the validity check and the action that depends on it inside a single transactional boundary, so that from the outside the check-and-use is one indivisible step with no interval in which the referent can be revoked, consumed, or overwritten by someone else. Its defining property is all-or-nothing consistency — if the precondition does not hold when the boundary tries to commit, the whole unit aborts and rolls back to a consistent prior state, never leaving a half-applied change. It is not a faster check; it is a guarantee about when the check is true relative to the use, enforced across a whole multi-step region rather than a single instruction.
Example¶
Two buyers race for the last seat at a concert. A naïve flow reads "1 seat available," then writes a booking — and because the read and the write are separate, both buyers pass the check and the seat is sold twice. The Transactional Precondition Guard runs the availability check and the booking write inside one database transaction, holding the row so the check's truth is preserved through the write (SELECT ... FOR UPDATE, or a serializable isolation level).[1] The first transaction to commit takes the seat; the second finds its precondition — "seat still available" — false at commit time, and the entire transaction aborts and rolls back, leaving no partial booking behind.
The buyer who lost sees a clean "sold out," not a phantom reservation. The system never enters the inconsistent state — one seat, two owners — that the check-then-act gap would otherwise allow.[n1]
How it works¶
- Bind check to use in one boundary. Place the precondition validation and the dependent action inside the same transaction or guarded critical section, so no interleaving can invalidate the referent between them.
- Close the race window. Hold or version the referent for the boundary's duration — a lock, or an isolation level strong enough for this specific race — so a concurrent writer cannot slip in undetected.
- Commit only if the precondition still holds. Re-verify at commit; if the referent changed, the commit fails rather than applying against a stale premise.
- Abort atomically on failure. A failed precondition rolls the whole unit back to a consistent state — all-or-nothing, never a partial write — so failure is uniform and leaves no debris.
Tuning parameters¶
- Isolation strength — how strongly the boundary serializes against concurrent actors. Stronger isolation (serializable) closes more races but reduces throughput and invites conflicts; weaker isolation is faster but may leave the very race unguarded.
- Locking discipline — pessimistic (lock up front) versus optimistic (proceed, verify at commit). Pessimistic avoids wasted work under high contention; optimistic scales better when conflicts are rare.
- Boundary scope — how much work sits inside one transaction. A tight boundary holds locks briefly and blocks fewer others; a wide one guards more invariants but starves throughput and risks deadlock.
- Conflict policy — on precondition failure, abort-and-retry versus abort-and-report. Retry rides out transient contention; report hands the decision on.
- Lock timeout — how long the boundary waits for contended referents before giving up. Short timeouts stay responsive but abort more; long ones persist but can pile up.
When it helps, and when it misleads¶
It is the right tool precisely when concurrent actors can invalidate a referent between check and use and a partial result is unacceptable: seat and inventory reservations, financial postings, uniqueness constraints, any invariant that must hold across several steps at once. Where a lone existence check leaves a race window, the guard closes it.
Its costs are the costs of serialization. Transactions contend, and heavy or wide boundaries deadlock or throttle throughput; a boundary drawn too large holds locks long enough to starve everyone else. The most dangerous misuse is false comfort — wrapping code in a transaction whose isolation level is too weak to actually stop the race it was meant to stop, so the guarantee is nominal, not real. And the guard only protects referents inside its boundary: an external call made mid-transaction is not magically transactional and can still act on a stale premise. The disciplines: match isolation to the specific race rather than defaulting, keep the boundary as tight as correctness allows, and pair the atomic abort with a fallback that decides what happens after rollback — the guard guarantees consistency, not recovery.
How it implements the components¶
check_use_binding_boundary— it is the boundary: the transactional region that fuses the precondition check to the dependent use so they cannot be pried apart by an interleaving.race_window_probe— by holding or versioning the referent and re-verifying at commit, it detects (and refuses) any concurrent change in the window that a separate check-then-act would miss.safe_abort_or_fallback_path— its abort is the atomic rollback to a consistent state: on precondition failure the whole unit is undone, guaranteeing no partial application.
It does not enumerate the operation's dependency set beforehand — that's Preflight Resource Probe; it does not determine that a referent has been deliberately killed — that's Revocation or Tombstone Check; and it does not choose the recovery route once it has aborted — that's Safe Missing-Referent Fallback, which decides what to do next.
Related¶
- Instantiates: Use-Time Referent Validation — Transactional Precondition Guard supplies the atomic check-and-use boundary that eliminates the race window a separate check leaves open.
- Consumes: Safe Missing-Referent Fallback — after an atomic abort, the fallback policy decides whether to retry, degrade, or surface the failure.
- Sibling mechanisms: Preflight Resource Probe · Safe Missing-Referent Fallback · Atomic Check-and-Use Operation · Compare-and-Swap or Version Guard · Lease, Lock, or Reservation Token · Revocation or Tombstone Check · Stale Reference Monitor · Just-in-Time Existence Check · Capability or Authorization Revalidation
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Transactional Precondition Guard operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing.
Independent corroboration: The frozen evidence defines Transactional Precondition Guard as 'Runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing', so its operative form is Control, Automation & Runtime.
Nearest alternative: Rule, Policy & Commitment — Transactional Precondition Guard includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Both independent reviews identify computer science as the historical home of the operation—Runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing.. The retained alternates document formative adjacent traditions; the reach field, not the origin field, carries later applicability.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a….
Review resolution: Both blind reviewers independently place the defining operation—Runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing.—in computer science. Their queued differences are secondary: origin_mode_disagreement, domain_reach_disagreement, encyclopedia_synthesis_disagreement. Reviewer A contributes no unique alternate; reviewer B contributes no unique alternate. I preserve the full evidence-supported union of 1 alternate domain(s), without a numeric cap. origin_mode=single_lineage reflects the reviewers' evidence about historical construction, while domain_reach=specialized separately reflects present-day portability. The affirmative encyclopedia-synthesis finding is preserved, and confidence=high uses the more conservative reviewer level.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The guard binds a check to a use within one transactional domain; it does not extend that guarantee across domains it doesn't control. A call to an external service made inside the transaction is not rolled back by the database's abort, so cross-system invariants need their own coordination (a compensating action, or a saga) rather than a false trust that the surrounding transaction covers them.
[n1] TOCTOU — time-of-check to time-of-use — is the real, named class of bug in which a referent validated at check time is changed by another actor before it is used. It is exactly the race window this guard exists to close. ↩
References¶
[1] PostgreSQL Global Development Group. PostgreSQL 18 Documentation: Chapter 13. Concurrency Control. PostgreSQL 18.6 Documentation, 2026. Documents the FOR UPDATE and serializable-isolation options named in the claim. registry ↩