The document discusses several concepts related to distributed data management including ACID properties, monitor object pattern, and sagas. The monitor object pattern describes how synchronized methods are used to control access to shared resources. Sagas are long-running transactions that coordinate multiple services through message passing. There are two types of sagas: choreography-based where the sequence is embedded in the message flow, and orchestration-based where a central process coordinates the steps. Issues like lost updates and dirty reads can occur without transactional isolation, and various countermeasures are proposed to handle the lack of isolation in a saga.

1. Distributed Data
Management
Challenges

2. Bond Trading

3. ACID
(Atomicity,
Consistency,
Isolation,
Durability)
A
• Each transaction is "all or nothing".
C
• Data should be valid according to all defined
rules.
I
• Transactions do not affect each other.
D
• Committed data would not be lost, even after
power failure.

4. Monitor
object pattern
Monitor object: This component exposes
the methods that are synchronized to the
clients
Synchronized methods: The thread-safe
functions that are exported by the
interface of the object are implemented
by these methods
Monitor conditions: This component along
with the monitor lock decides whether the
synchronized method should resume its
processing or suspend it

5. Monitor
object pattern

6. Sagas

7. Sagas

8. Sagas

9. Sagas
 Order Service— Create an Order in an APPROVAL_PENDING state.
 Consumer Service— Verify that the consumer can place an order.
 Kitchen Service— Validate order details and create a Ticket in
the CREATE_PENDING state.
 Accounting Service— Authorize consumer’s credit card, which fails.
 Kitchen Service— Change the state of the Ticket to CREATE_REJECTED.
 Order Service— Change the state of the Order to REJECTED.

10. Choreography-
based sagas

11. Orchestration-
based sagas

12. The lack of isolation
 Lost updates— One saga overwrites without reading changes made by
another saga.
 Dirty reads— A transaction or a saga reads the updates made by a saga that
has not yet completed those updates.
 Fuzzy/nonrepeatable reads— Two different steps of a saga read the same
data and get different results because another saga has made updates.

13. Countermeasures for handling the lack
of isolation
 Semantic lock— An application-level lock.
 Commutative updates— Design update operations to be executable in any
order.
 Pessimistic view— Reorder the steps of a saga to minimize business risk.
 Reread value— Prevent dirty writes by rereading data to verify that it’s
unchanged before overwriting it.
 Version file— Record the updates to a record so that they can be reordered.
 By value— Use each request’s business risk to dynamically select the
concurrency mechanism.

14. Order service