Re: [I] Regarding Distributed Transaction [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org