terrymanu commented on issue #37283:
URL:
https://github.com/apache/shardingsphere/issues/37283#issuecomment-3619398659
• Understanding
- On ShardingSphere-JDBC 5.5.1 with Seata 2.2.0, all @Transactional calls
are behaving like Seata global transactions. You want only
cross-service/cross-database operations to use a global transaction, and simple
single-service operations to
stay local. You also ask whether a single service that updates multiple
databases can rely on local transactions for rollback.
Root Cause (based on given info)
- ShardingSphere’s default transaction type is LOCAL; only when you
explicitly switch to BASE (Seata AT) or XA does it become a distributed
transaction (see official docs:
https://shardingsphere.apache.org/document/current/en/user-manual/
shardingsphere-jdbc/special-api/transaction/
(https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-jdbc/special-api/transaction/)).
- All @Transactional being treated as global usually means your data
sources are proxied by Seata (auto data source proxy), or ShardingSphere’s
default transaction type is set to BASE/XA. The exact cause needs your current
configuration to
confirm.
Analysis
- Local transactions only guarantee atomicity within a single data source;
even within one service, cross-database updates need a distributed transaction
(Seata BASE/XA) to ensure consistency.
- To keep most calls local: keep ShardingSphere’s default transaction type
as LOCAL; avoid Seata auto-proxying every data source (or only proxy the ones
that need global transactions); and annotate only the operations that truly
need global
consistency with @GlobalTransactional, switching the transaction type to
BASE before those calls (per the doc above).
- If everything is still taken over, we need to inspect which transaction
manager Spring is picking and how the data sources are proxied.
Conclusion
- This looks like a configuration/usage issue (global proxying or default
transaction type), not a ShardingSphere bug.
- Suggested next steps: ensure default transaction type remains LOCAL,
limit Seata data source proxying to the paths that need global transactions,
and explicitly opt into BASE/XA only where strong consistency is required.
- To pinpoint further, please share: Seata settings (whether auto data
source proxy is enabled), the active Spring transaction manager, and your
ShardingSphere transaction type configuration.
--
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]
