java - Atomikos vs. Bitronix vs. JBossTS - MVCC 和嵌套事务

Question

我想实现前事务管理器之一。但是，由于我仍处于概念阶段，我想尝试所有这些事务管理器。我最终选择的标准是易用性、Tomcat 的使用、适应性以及对嵌套事务和 MVCC 的大部分支持。

我找不到任何关于 Bitronix 和 Atomikos 可能支持后一个标准的信息。

我知道 JBossTS 支持 MVCC 和 NT - 但我不确定 JBoss 是否是一个很好的选择，考虑到使用 JBoss 带来的巨大开销......特别是对于 Spring 和 hibernate 的用户。

您知道 Atomikos 和/或 Bitronix 是否符合我的标准 - 或者实现我自己的 TM 会更好吗？

Answer 1

您需要更清楚地定义您的要求。 “嵌套事务”含糊不清。这可能意味着简单地暂停一个事务以运行另一个事务，然后恢复第一个事务:

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.

乍一看这很吸引人，但当发生嵌套回滚时，会带来更多麻烦。没有得到广泛支持，尽管一些数据库允许这样做使存储过程处理更容易。

最后，您拥有真正的嵌套事务，其中子事务从其父事务继承锁，并在完成时将自己的锁传递给该父事务

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，而其他一些数据库支持表、页或行级锁定。事务管理器不知道也不关心。