terrymanu commented on issue #26754:
URL:
https://github.com/apache/shardingsphere/issues/26754#issuecomment-3552965818
## Issue Understanding
The report at https://github.com/apache/shardingsphere/issues/26754
(https://github.com/apache/shardingsphere/issues/26754) references
docs/document/content/features/transaction/_index.cn.md and argues that, in a
single-service cross-database scenario, XA transactions
should be faster than Seata BASE (AT), thus questioning the documentation
statement that “XA fits high-consistency/low-concurrency, BASE fits high
concurrency.”
## Root Cause
The official documentation
(https://github.com/apache/shardingsphere/blob/master/docs/document/content/features/transaction/_index.cn.md#shardingsphere-xa-%E4%BA%8B%E5%8A%A1%E4%BD%BF%E7%94%A8%E5%9C%BA%E6%99%AF
(https://github.com/apache/shardingsphere/blob/master/
docs/document/content/features/transaction/_index.cn.md#shardingsphere-xa-%E4%BA%8B%E5%8A%A1%E4%BD%BF%E7%94%A8%E5%9C%BA%E6%99%AF)
and
https://github.com/apache/shardingsphere/blob/master/docs/document/content/features/transaction/_index.cn.md#shardingsphere-
base-%E4%BA%8B%E5%8A%A1%E4%BD%BF%E7%94%A8%E5%9C%BA%E6%99%AF
(https://github.com/apache/shardingsphere/blob/master/docs/document/content/features/transaction/_index.cn.md#shardingsphere-base-%E4%BA%8B%E5%8A%A1%E4%BD%BF%E7%94%A8%E5%9C%BA%E6%99%AF))
stresses that XA
transactions suffer from synchronous blocking: locks on each branch stay
held until the global commit/rollback, throttling concurrency. BASE (Seata AT)
releases physical locks after phase one, keeping only logical locks and undo
info, so throughput is better when
temporary inconsistency is acceptable. The reporter conflates
per-transaction overhead (undo/mirror writes) with system-level concurrency and
incorrectly attributes the difference to cross-service waits.
## Analysis
- In ShardingSphere-JDBC, XA still runs the classic prepare →
commit/rollback flow; all affected rows stay locked until the transaction
manager decides, regardless of whether branches run in one process or multiple
services, so hot rows block concurrent access.
- BASE (Seata AT) commits the local transaction in phase one, releases DB
locks, and relies on undo logs plus logical locks to ensure eventual
consistency, which is why it is described as “performance is better, suitable
for high concurrency” in the docs.
- Overturning that guidance requires benchmark evidence (DB type/version,
SQL, transaction length, concurrency level, TPS/latency, cross-service
presence, etc.). Without such data, the claim cannot be generalized and would
mislead other users’ technology choices.
## Conclusion
This is a misunderstanding of XA vs. BASE characteristics rather than a
documentation bug. Please follow the existing recommendations:
- Use XA where strong consistency and lower concurrency are acceptable.
- Use BASE (Seata AT) when high concurrency is required and brief
inconsistency is tolerable.
If you still believe XA outperforms BASE in general single-service
cross-database scenarios, please share full benchmark data as outlined above so
the community can reassess the documentation.
--
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]
