Transaction Overview and Implementation Strategies: Database, Spring, and Distributed Solutions

1 Overview

Transactions have four properties, commonly known as the ACID properties.

Many articles discuss extensions such as two‑phase commit, three‑phase commit, and TCC for distributed transactions; this article focuses on presenting the effects, advantages, and disadvantages of different solutions.

The following scenarios do not consider middleware exceptions, such as message loss caused by MQ failures.

2 Implementation Methods

Bottom‑up transaction implementation approaches

2.1 Database Transaction Implementation

Method

Uses data lock mechanisms, MVCC version control, redo log, and undo log to ensure consistency.

Effect

Database locks, redo log, and undo log guarantee data write or rollback consistency.

MVCC version control ensures controlled query ranges.

2.2 Spring Single‑Datasource Transaction Implementation

Method

Leverages AOP aspects and manual database commit mode to ensure consistency of a whole business process.

Effect

All DML operations within the aspect are controlled by the transaction.

The Spring transaction propagation mechanism provides diverse transaction control.

2.3 Distributed Transaction Implementation

Method

Final consistency using RocketMQ or custom final‑consistency logic.

Distributed transaction framework Seata.

Effect

Achieves data consistency across multiple distributed applications, allowing large systems to be split into smaller services.

3 Scenario Analysis

Scenario: User places an order while deducting a coupon.

3.1 Single‑Server Implementation

Implementation Model and Process

Pros and Cons

Pros: Simple system, guarantees transaction consistency.

Cons: Suitable only for single‑service systems; as order and coupon functions grow, coordination cost becomes high.

3.2 Microservice (Non‑Distributed Transaction) Implementation

Implementation Model and Process

Pros and Cons

Pros: Order and coupon systems are split, reducing coordination cost.

Cons: RPC calls between systems can cause inconsistencies in various failure scenarios.

RPC timeout: Order service times out while coupon service succeeds, leading to coupon deduction without order.

System exception: Coupon deducted successfully but order service crashes before committing.

Rollback failure: Coupon deducted, order fails, and rollback call to coupon service fails.

Simple optimization: For this specific scenario, use a pre‑deduction + timed callback confirmation (similar to a three‑phase commit) because orders are automatically cancelled after timeout.

The above solution is lightweight and has low business intrusion, but it is not a universal approach.

3.3 Microservice Distributed Transaction Implementation

3.3.1 Implementation Model and Process (Method 1)

Pros and Cons

This method has the following drawbacks:

Waiting for ACK after sending a message reduces concurrency; not waiting may cause message loss while the order succeeds.

Message sending must be the last step to avoid rollback of coupon deduction if subsequent logic fails.

If the system restarts after the message is sent but before the order transaction commits, the coupon may be deducted while the order fails.

Optimization: Add the timed callback confirmation logic for coupons; if the order fails or does not exist, roll back the pre‑deduction.

3.3.2 Implementation Model and Process (Method 2)

Pros

Solves the performance issue of method 1.

Improves fault tolerance by using scheduled retries for message sending.

Includes coupon timed callbacks.

Cons

Introduces heavier logic compared to a single‑service system.

3.3.2 Multi‑System Deduction

For multiple systems, change the message to broadcast mode; when an order succeeds, broadcast the message and let downstream services decide how to handle it.

4 Summary

Through iterative solutions, two critical points emerge for achieving consistency in distributed transactions: reliable message sending and handling exception‑induced incorrect deductions. The final approach uses (1) a local‑transaction‑table‑like pattern with scheduled tasks to guarantee message delivery, and (2) a pre‑deduction plus timed‑callback confirmation pattern to roll back erroneous deductions.

These enhancements provide high consistency but introduce additional unconventional logic into the system.