Atomikos vs. Bitronix vs. JBossTS – MVCC和嵌套事务
我想实现前一个事务管理器。 但是，由于我还处于概念阶段，我想尝试所有这些事务管理器。 我最后选择的标准是易用性， Tomcat的使用，适应性以及嵌套事务和MVCC的大部分支持。
我无法找到有关Bitronix和Atomikos后一种标准的可能支持的任何信息。
我知道JBossTS支持MVCC和NT – 但我不确定JBoss是否是JBoss使用带来的巨大开销的一个很好的选择…特别是关于Spring和hibernate的用户。
你知道Atomikos和/或Bitronix是否适合我的标准 – 或者实现我自己的TM会更好吗？
您需要更清楚地定义您的要求。 ‘嵌套交易’含糊不清。 这可能意味着简单地暂停一个事务以运行另一个事务，然后恢复第一个事务：
transactionManager.begin(); // now in tx A transaction txA = transactionManager.suspend(); // no tx active here transactionManager.begin(); // now in tx B transactionManager.commit(); // tx B ends // no tx active here transactionManager.resume(txA); // now in tx A again transactionManager.commit(); // tx A ends 这在您需要执行某些操作（例如审计日志更新）时很常见，该操作在逻辑上与外部事务分开。 任何事务管理器都会这样做，尽管编写直接驱动TM的代码是很少见的。 请改用EJB容器。
那么你就有了这样一种情况，你只需要伪嵌套就可以更容易地构造逻辑：
// no tx active at start transactionManager.begin(); // tx A now active, nesting count = 1 transactionManager.begin(); // tx A still active, nesting count = 2 transactionManager.commit(); // nullop, tx A still active, nesting count = 1 transactionManager.commit(); // tx A really committed, no tx active, count = 0.
乍一看这看起来很有吸引力，但是当嵌套回滚发生时会导致更多的麻烦。 虽然有些数据库允许这使得存储过程处理更容易，但并未得到广泛支持。
最后，您有真正的嵌套事务，其中子事务从其父事务inheritance锁，并在完成时将其自己的锁传递给该父事务
transactionManager.begin(); // now in tx A1 transactionManager.begin(); // now in tx A1.1 // can see uncommitted changes made by A1 transactionManager.commit(); // validate ability to make A1.1 changes permanent, but do not actually do so yet // now in tx A1, still holding locks from A1.1 also transactionManager.commit(); // commit A1 and A1.1 changes atomically.
这主要用于故障隔离 – 可以回滚子事务并执行其他操作，而不会对外部事务造成任何影响。 这是一个非常强大的交易模型。 实现起来也很棘手 – 只有JBossTS目前支持它。 并不是说它对大多数Java EE用例都有好处，因为没有资源管理器即数据库或消息队列支持它。
至于MVCC，这根本与事务管理器无关。 您的业务数据保存在资源管理器中，通常是关系数据库。 RM用于提供tx隔离和并发控制的模型与事务驱动的方式正交。 Oracle和postgres支持MVCC，而其他一些dbs则支持表，页或行级锁定。 交易经理不知道或不关心。
这篇新闻组的post提到，截至2010年，没有计划支持Bitronix中的嵌套交易，而且它们似乎确实有些异乎寻常的要求。
Atomikos TransactionsEssentials数据表将嵌套事务列为function。
不仅JBoss支持嵌套事务：Atomikos也是如此……嵌套事务对经典（XA）事务没有用，但它们适用于高级SOA事务模型，如Atomikos TCC（Try-Confirm / Cancel）。