의미적 잠금 및 동시 사가

Sagas relax isolation: intermediate states are visible to other transactions. When two sagas touch the same data concurrently, you risk dirty reads, lost updates, and fuzzy reads.

This lesson covers countermeasures that restore safety without full ACID isolation.

A lost update happens when one saga overwrites a change made by another that it did not see.

• Saga A reads balance 100.
• Saga B reads balance 100, subtracts 30, writes 70.
• Saga A subtracts 50 from its stale 100, writes 50.

B's deduction is lost.

A semantic lock marks a record as in-progress using an application-level flag, not a database lock.

For example, set an order's status to PENDING. Other sagas see the flag and refuse to act until the saga commits or compensates.

The semantic lock is released by the final saga step or by the compensating transaction. The status moves to APPROVED or back to AVAILABLE.

Design updates that can be applied in any order and produce the same result. Addition and subtraction on a balance are commutative; setting an absolute value is not.

Prefer balance += delta over balance = newValue.

Reorder saga steps so that the steps most likely to fail run first, minimizing the window during which dirty data is exposed.

If a risky step succeeds early, later steps are far less likely to need compensation.

Before writing, reread the record and verify it has not changed since you read it. If it changed, abort and retry. This is optimistic concurrency control.

Store a version column with each record. Each update increments the version and includes the expected version in the WHERE clause.

• If zero rows update, someone else changed it first.
• The saga retries with fresh data.

Choose your concurrency strategy by the business risk of the data. High-value records (large payments) get strict semantic locks; low-risk records use looser, more available approaches.

Real systems mix several techniques: a semantic lock to mark in-progress orders, commutative updates for counters, and version checks for critical writes. The goal is to keep sagas correct while preserving availability.

Every countermeasure adds complexity. Semantic locks can cause contention; rereads add round-trips. Choose the lightest mechanism that prevents the anomalies your domain actually cares about.

Which countermeasure marks a record as in-progress using an application-level status so other sagas refuse to act on it?

You learned countermeasures for concurrent sagas:

• Semantic locks flag in-progress records.
• Commutative updates make order-of-application irrelevant.
• Pessimistic view reorders risky steps first.
• Reread/version checks catch concurrent changes.

Together these restore safety without full ACID isolation.