FAQ

FAQ

一、ByteTCC为什么要基于事务管理器（TransactionManager）来实现TCC全局事务？

1.1、首先，TCC事务既然属于事务处理范畴，使用TransactionManager来实现应该说是自然而然的思路；
1.2、其次，Java平台中，主流的bean容器（如EJB、spring）都采用声明式事务机制来管理应用程序的事务，通过委托TransactionManager模块来管理事务，因此使用TransactionManager的实现方式可以作为独立模块与bean容器无缝衔接；
1.3、由于bean容器的事务处理均由TransactionManager接管，因此在TCC全局事务中TransactionManager对各阶段service绑定哪些资源以及资源事务（如数据库事务）的开启、完成情况可以有比较精准的掌握，有助于控制全局事务；相反，如果在应用系统层实现TCC全局事务，则效果控制效果要差很多，例如全局事务可能不太容易获知service参与的资源事务的提交/回滚情况。如果try阶段service的资源事务的提交/回滚情况无法获知，就无从判断该service对应的cancel操作是否应该执行；如果confirm/cancel阶段service参的资源事务的提交/回滚情况无法获知，就无从判断该confirm/cancel是否仍然需要再次执行，因而只能通过要求业务系统操作自行保证幂等性，并通过反复执行来保障confirm/cancel被成功调用（一来业务系统逻辑复杂度高，二来由于confirm/cancel操作可能会被反复多次执行，也导致性能开销较大）。

二、ByteTCC为什么要兼容JTA规范？

JTA是Java平台中的事务管理规范，它为事务管理器和资源管理器、应用服务器定义了标准的事务处理接口，被主流的bean容器所兼容。因此，兼容JTA规范，有助于ByteTCC对各类资源管理器的支持和对各类bean容器的支持。

三、兼容JTA会不会导致ByteTCC性能低下？

1、JTA（Java Transaction API）仅是一套接口而已，并不会直接造成性能问题，各JTA实现的性能是否低下更关键的还是取决于各自的实现方式；
2、JavaEE平台中的事务可分为LocalTransaction、XATransaction两种：1）LocalTransaction，即本地事务，通过ResourceManager直接支持来实现，例如可以通过java.sql.Connection的commit()和rollback()方法提交和回滚的事务就属于LocalTransaction；2）XATransaction，即分布式事务，基于两阶段事务提交机制实现的事务。这两种事务中，只有XATransaction属于分布式事务范畴，也网上争议较多的，因为使用2pc机制，所以性能较差。
3、ByteTCC仅使用LocalTransaction来管理各阶段（Try/Confirm/Cancel）service参与的普通事务，并没有使用XATransaction，所以不会因为兼容JTA而造成性能低下。