Sumit6307 commented on PR #8007:
URL: https://github.com/apache/incubator-seata/pull/8007#issuecomment-4065007514
> The two transactions committed successfully because they were committed at
different times, so the "First-Committer-Wins" mechanism doesn't provide any
help in this scenario.
>
> As for the snapshot you mentioned, due to the absence of row locks or
table locks, the "select for update" operation, which is supposed to acquire
the row count before executing DML statements to ensure the accuracy of the
before image, fails to work. Without an accurate before image, it's impossible
to guarantee the accuracy of the rollback data when the two-phase decision
results in a rollback.
>
> The prerequisite for creating an accurate before image in Seata AT is a
current read, not a snapshot read.
@funky-eyes
@funky-eyes Thank you for the technical guidance. I completely agree with
your assessment: **ClickHouse fundamentally performs Snapshot Reads, and
without a native row-level "Current Read" (SELECT FOR UPDATE), a race condition
exists where Seata could capture a stale before-image.**
Since ClickHouse's architecture (MergeTree + MVCC) makes a traditional
OLTP-style "Current Read" impossible, I propose we solve this at the **Seata
Protocol level** for this specific resource manager:
1. **Serialization via Global Lock:** In this implementation, the **Global
Lock** becomes our primary source of truth. By ensuring the RM captures the
Before-Image **only after** successfully securing the Global Lock, we create a
logical barrier. If TX1 holds the Global Lock, TX2 will be blocked at the
[branchRegister](cci:1://file:///c:/Users/Sumit/OneDrive/Desktop/GSOC-2026/gsoc_incubator-seata/gsoc_incubator-seata-2/rm/src/main/java/org/apache/seata/rm/AbstractResourceManager.java:60:4-111:5)
stage and won't be able to fetch its (potentially stale) before-image until
TX1 releases the lock.
2. **Addressing External Writers:** I acknowledge that external writers
(not using Seata) could still bypass this. However, for users who manage their
ClickHouse mutations exclusively through Seata, this "Global Lock +
Post-Registration Fetch" pattern provides the necessary distributed consistency.
3. **Experimental Status:** Given ClickHouse’s OLAP nature, I propose we
support this as an **Experimental Feature**. We can document that:
* It relies on **Global Lock Serialization** rather than DB-level
local locks.
* It requires `mutations_sync=1` to ensure synchronous persistence of
the undo-log context.
This PR provides the essential SQL Dialect and SPI infrastructure for
ClickHouse. Would you be open to merging this with an **"Experimental"** tag
and clear documentation on these isolation trade-offs? This allows the
community to start using Seata with ClickHouse while we continue to refine the
consistency model.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
