同一个服务多数据源操作，针对同一个数据源的分支事务进行合并

[PeppaO]

有两个服务，一个服务，直接跨数据源，但是又不想改自己应用，希望seata可以考虑兼容这种场景，比如数据源1操作数据1，数据源2操作数据2，数据源1又操作1，实现第一三步合并为一个分支事务，否则这种场景下seata无法使用，这样的需求应该挺合理的。

[PeppaO]

@funky-eyes @slievrly

[funky-eyes]

I believe this scenario, where a single service has multiple data sources all managed by Seata in XA mode, is a valid one. The challenge is that once an XA transaction is in the 'prepare' phase, it cannot be re-entered. This means Seata cannot support business logic that involves multiple modifications to the same resource within that transaction.

Therefore, I think we could potentially offer a multi-datasource transaction solution. This solution could use either XA or AT mode at its core. Importantly, it would support connection reuse within the multi-datasource transaction. This would allow for resource re-entry and also prevent the creation of multiple branch transactions.

This idea is somewhat similar to the multi-datasource transaction functionality I contributed to the dynamic-datasource project (baomidou/dynamic-datasource#316). Of course, that particular implementation doesn't use Seata XA or AT mode underneath, so it doesn't guarantee strong consistency."

[PeppaO]

requirement that needs to be realized, and this scenario should exist.

[xjlgod]

Currently, in AT mode, separate branch transactions are created and can function normally, but in XA mode, does it throw errors due to non-reentrancy? I reviewed the dynamic data source PR(baomidou/dynamic-datasource#316), which essentially unified connection management for commit and rollback. Can XA mode be modified, but is it necessary for AT mode? Or can users choose?

[PeppaO]

I think AT mode is not needed at present. It is mainly for XA mode. Users hope to achieve it without modifying the code.

[funky-eyes]

In AT mode, this method can reduce the creation of branch transactions because multiple DML executions against the same data source all use the same connection.