分布式环境运行下job运行潜在错误 about tcc-transaction

[changmingxie]

@streammemoryli

你的项目是user和order两个不同的项目，并且都有root事务？ 如果是这样，tcc_transaction 表 不能共用一个表，会存在你说的第2点问题。
第1点问题 不会出现，各个实例的job在恢复时使用乐观离线锁机制(事务日志的version）来保证只有一个job能恢复一个root事务。

[streammemoryli]

第一点，是否可考虑使用quartz 数据库持久化 方案，来完全避免

[tanhongjie9012]

@changmingxie
如果多个有root事务的项目没办法共用一个tcc_transaction表，是不是也意味着事务的日志和事务恢复机制没办法统一管理？

[changmingxie]

@tanhongjie9012 看怎么统一管理了，放在一个地方只是分区到不同的存储(表）也是可以的。多个项目放在同一个存储（表）里不太推荐！

[tanhongjie9012]

@changmingxie
我在探讨一种可能性，将多个有root事务的项目共用一个存储（表），然后将事务恢复机制recover抽离出来进行统一的事务恢复处理。

即把框架拆分为两个部分，一个是嵌入到应用AP中的client，进行事务的控制和日志的收集（即框架中tcc-transaction-spring）；另一个是独立部署的recover service，根据日志执行统一的事务恢复job。

目前遇到的难题就是recover service进行confirm或rollback阶段，无法在Terminator中根据InvocationContext在本地找到对应的bean执行invoke方法。如果把对应的事务代码都引入到recover service中，那recover service就会跟事务代码高耦合，这似乎并非合理的解决方案。

以上只是一个尝试性的想法，不知作者巨巨你怎么看，或者有什么建议？

[changmingxie]

@tanhongjie9012
你提的也是一个不错的思路呢，据我所知，蚂蚁金服的分布式事务服务DTS（https://www.cloud.alipay.com/docs/middleware/xts/index.html）采用的是client-server模式。目前tcc-transaction还不是以服务的形式供，接下来 可以考虑，提供一个更完善的解决方案。

[streammemoryli]

期待能看到集中式job管理