In a non-blocking service, how can a lost asynchronous context make statements run outside the intended transaction or on a second connection?
answer
- ambient context assumes one thread
- resumption lands elsewhere
- empty slot means its own connection
- worse: another request's transaction
- propagate along the continuation, not the thread
basics
~20 sA blocking layer keeps the current unit of work in thread-bound storage. Non-blocking work resumes on other threads, so that slot is empty or holds another request's context, and the statement quietly runs on its own connection.
solid answer
~40 sBlocking data-access layers park the active unit of work, transaction and connection in storage bound to the current thread, which works because the whole request stays on one thread. Non-blocking work does not: each resumption may land on a different carrier thread. A lookup then finds nothing — so the statement opens its own connection and commits outside the intended transaction — or finds another request's context and joins the wrong transaction. Carry the context **explicitly** instead: pass the handle as a parameter, or use a context object the runtime propagates along the continuation chain, and make the transaction boundary a function that owns the whole body. Then guard it: never capture the handle into work scheduled outside the boundary, and never take a second pooled connection while holding one.
go deeper
Take away the core fact: the current transaction used to be found automatically because the request stayed on one thread, and once work resumes on other threads that lookup can find nothing.
Explain the three outcomes — no context so the statement commits on its own, someone else's context, or the right context but a second connection — and why a second connection means a second transaction.
Show how you would catch it: connection and transaction identifiers on every statement, a boundary that errors when no context is present, a deliberate rollback test, and pool-exhaustion traces showing nested acquisition.
Decide the house convention once — explicit handle or runtime-propagated context — and enforce it, because a codebase mixing ambient lookup with non-blocking execution produces load-dependent isolation bugs no review reliably catches.
## Why the thread-bound slot stops working A blocking data-access layer usually keeps the *current* unit of work — its tracked objects, its transaction, and the connection that transaction is pinned to — in storage attached to the running thread. Any code called anywhere below the transaction boundary can ask "what is the current unit of work?" and get the right answer, without threading a parameter through ten layers. The mechanism is invisible precisely because the request occupies one thread from first line to last. Remove that assumption and the mechanism breaks. In a non-blocking service, a piece of work runs until it needs I/O, hands the thread back, and is resumed later — often on a **different** carrier thread from a shared pool. Everything before a resumption point may have executed somewhere else. So a lookup in thread-bound storage after resumption is a lookup on the wrong thread. ## Three shapes the failure takes 1. **The slot is empty.** The layer finds no current unit of work and does the accommodating thing: it takes a fresh connection, runs the statement on its own, and commits immediately. The caller believes the write is inside its transaction. It is not — a later rollback leaves that write behind, and a read that was supposed to see uncommitted changes from earlier in the same transaction does not. 2. **The slot belongs to somebody else.** A carrier thread is reused across requests. If the context was left behind rather than cleared, the resumed work may find a *different* request's unit of work and enrol its statements in a stranger's transaction. This is the dangerous one: correctness and isolation both break, and it is load-dependent, so it never reproduces on a developer machine. 3. **The right context, on a second connection.** The context is found, but a nested call acquires its own connection anyway — a second data source, a helper written for the blocking path, a fan-out that runs sibling statements in parallel. Statements on two connections are in two transactions no matter what the call stack looks like. If the pool is saturated, that second acquisition can also wait on a connection that only the first one's completion could release: a self-inflicted stall. ## Carrying the context correctly - **Pass it explicitly.** The unit of work is a value in the signature of every function that runs statements. Verbose, but a lost context becomes a compile-time or review-time problem instead of a production one. - **Use a propagated context object.** Most non-blocking runtimes offer a per-operation context carried along the continuation chain rather than pinned to a thread. Put the unit of work there. The ergonomics look like the old ambient lookup, and the propagation is the runtime's job. - **Make the boundary own the body.** Express a transaction as a construct that takes the entire unit of work as a callback and passes it the handle. Nothing inside can accidentally run after the commit, because the commit is the boundary's last act. - **Never let the handle outlive the boundary.** Capturing it into work scheduled elsewhere — a fire-and-forget task, a cache callback, a retry queued for later — produces statements on a closed or committed transaction, or on a connection that has been returned to the pool and handed to somebody else. - **Do not fan out on one connection.** A single connection generally does not support concurrent statements. Sibling operations inside one transaction must be sequential; if they must be parallel, they need separate transactions and you must accept that they are separate. ## Detecting it before a customer does - Include a connection identifier and a transaction identifier in the statement log, then check that everything inside one boundary shares both. A stray identifier is the smoking gun. - Instrument the boundary to fail loudly when a statement is issued with no context, instead of silently running it stand-alone. "No current unit of work" should be an error in a service that always intends one. - Write a test that rolls back deliberately and asserts that *nothing* survived. A write that persists through a rollback is the cheapest possible detector of shape one. - Watch for pool exhaustion whose stack shows an acquisition while another is already held; that is shape three. ## The rule underneath Ambient context is a convenience bought with an assumption — one request, one thread, start to finish. Non-blocking execution withdraws the assumption, so the convenience has to be repaid either by explicit parameters or by a runtime that propagates context along continuations. Anything that keeps the old lookup while relaxing the assumption is not a smaller version of the same design; it is the same design with its precondition removed.
- Why is finding another request's context worse than finding none at all?An empty slot degrades predictably: the statement runs stand-alone, and a rollback test catches it. A borrowed context corrupts two requests at once — statements enrol in a stranger's transaction, so one request's rollback discards another's writes and isolation guarantees stop meaning anything. It is also load-dependent, so it shows up only in production.
- Can sibling statements inside one transaction be run in parallel to cut latency?Generally not on one connection, which serialises statements anyway or rejects concurrent use. Running them in parallel means separate connections, and separate connections mean separate transactions with no shared atomicity or read view. If the latency matters more than atomicity, split them deliberately and say so; do not let a parallel helper decide it for you.
- What makes a second connection acquired inside an open transaction a stall risk?The first connection is held for the whole boundary, so the request needs two of a bounded resource at once. Under load, enough requests holding one and waiting for a second can consume the pool, and none can release until it gets what nobody will free. The pool is not deadlocked by locks but by its own bound.
saying these in an interview costs you the question
- Assumes thread-bound context still works because the code looks sequential
- Says a missing unit of work would obviously throw rather than run stand-alone
- Runs sibling statements in parallel inside one transaction to save time
- Captures the transaction handle into work scheduled after the boundary
- Blames the database when a rolled-back write is still present
- Treats a borrowed context from another request as merely a logging oddity