Transactions from the Application

A transaction commits or rolls back as a whole, so the boundary must enclose everything that has to be all-or-nothing - usually one use case. Per-call commits make each write permanent on its own, so a later failure leaves half-written data.

A translation step maps engine-specific codes and messages onto a small portable set of failure kinds - constraint violation, deadlock victim, serialization failure, lock or statement timeout, lost connection - so calling code branches on the kind, not on a number.

The layer turns the read into a locking read, so the row is claimed for your transaction as it is fetched. Other writers of that row wait. The lock is released only when the transaction boundary ends.

A read-only unit stops keeping a value snapshot of each loaded object, so no dirty check and no flush run at the end. Reads get a lighter, cheaper path, and anything modified inside the unit is simply not written.

Propagation decides what an inner bounded call does when a transaction is already running: join it, suspend it for an independent one, refuse to run unbounded, or open a nested scope that can be discarded on its own.

Interception happens as a call passes through the wrapper. A method calling another on the same object uses the object's own reference, so the wrapper is never crossed, no boundary begins, and the inner method's declared attributes are silently ignored.

A rejected flush leaves the tracked objects out of step with the stored rows and normally condemns the unit, so anything written afterwards is discarded at commit. The unit has to be abandoned and rebuilt, not repaired in place.

The layer puts the version value it loaded into the update's where clause and advances the version in the same statement. If the statement reports zero rows changed, another writer moved the row on, and the layer raises a conflict error.

The copy in the tracked set was read without a lock, so another transaction may have committed since. A lock taken without re-reading protects a row whose current values you have never seen. Your write then loses that change.

Publishing before the commit risks a false positive: the notification survives a rollback and announces a change that never landed. Publishing afterwards risks a false negative: the change is durable but the notification can vanish.

Outside the transaction boundary. Each attempt starts a new unit with an empty tracked set and reloads the data it works on, because objects from the failed attempt belong to a rolled-back transaction. Bound the attempts and keep the operation idempotent.

The version travels out in the transfer model and comes back with the submitted edit, so the write compares what the user actually saw. A path that re-reads the row and copies fields onto it compares nothing.

Resolve the tenant and bind its datasource or schema before the first statement, since the connection is fixed for the unit's life. On release, reset any state the switch set, or the pool lends the connection out still pointed there.

Replication is asynchronous, and each unit is routed on its own declared attributes with no memory that an earlier unit in the request wrote. The fix is a request-scoped pin sending later units to the primary.

A before-commit hook still runs inside the transaction, so it can inspect the unit's whole change set, add writes to it, and veto the commit by throwing. The cost is a longer transaction holding locks, and external calls there stay unsafe.

By the time an after-commit callback runs, its unit of work is finished. The tracked set is closed, so a link that was never loaded has nothing left to resolve it, and a write has no transaction to join.

Declarative demarcation attaches the boundary to a method as metadata and lets a wrapper begin, commit or roll back around the call. Programmatic demarcation writes those steps in the code, buying exact scope and runtime-chosen attributes at the cost of boilerplate.

Because the failure already marked the unit rollback-only. That flag lives on the transaction, not on the exception, so catching and discarding the exception leaves the unit condemned and the boundary refuses to commit it.

A version conflict appears only when the guarded statement runs - at a flush inside the unit, or at commit - never when the object is changed in memory, so the error can arrive after the service method has returned.

A counter only has to differ from the previous value, so it is exact and cheap. A timestamp also serves as a last-changed column but breaks on two writes in one clock tick, on clock skew, or on precision lost in transit.

Only the rows the layer read to build that object. An unloaded reference and child-collection rows are separate rows, so they can change while you hold the lock unless you request an extended scope.

The read-only marking declared on the unit is the usual routing signal, and it is read before the unit takes a connection. That connection then points at one server for the unit's whole life, so nothing can re-route it later.

Usually it is discarded: with no snapshot and no dirty check, the layer emits no update and the unit commits having written nothing. Some layers instead declare the transaction read-only and reject the write.

A timeout caps how long one unit may hold locks and a connection, so one stuck statement cannot pile callers up behind it. When the deadline passes the unit is failed and rolled back in full - nothing partial survives.

Read the constraint name from the translated failure and map it through a table the application owns, never by parsing the message. Because the unit is condemned, build the response from values captured before the flush, after the rollback.

Any statement not emitted for a tracked object - a set-based update, a hand-written fix, another service - neither compares nor advances the version unless it says so. Write the increment into those statements and re-read anything already loaded.

Because changes are buffered and sent at flush, and the layer orders those statements by its own rules rather than by the order your code made them. Locks are taken when statements run, so the flush order is the acquisition order.

By default the request queues for as long as the holder keeps the row. A wait timeout or an immediate-failure request bounds it, turning the block into an error that rolls the unit of work back.

Start from the invariant: only a state no reader may ever observe justifies one boundary. Otherwise weigh a long unit's lock time against the obligation a split creates - an intermediate state that must be detected, resumed and safely repeated.