WXingSong commented on issue #37283: URL: https://github.com/apache/shardingsphere/issues/37283#issuecomment-3619601545
> • Understanding > > * On ShardingSphere-JDBC 5.5.1 with Seata 2.2.0, all [@transactional](https://github.com/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](https://github.com/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. My Sharding-JDBC related configuration ``` transaction: defaultType: BASE providerType: Seata ``` Seata related configuration ``` seata: enable-auto-data-source-proxy: false ``` Do you mean that I should change the configuration to LOCAL and remove Seata’s enable-auto-data-source-proxy: false setting, and then use Seata’s @GlobalTransactional only when I need global transactions across services, right? ``` transaction: defaultType: LOCAL ``` -- 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]
