Atomikos 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.

乍一看，这看起来很吸引人，但是当嵌套回滚发生时，会引起更多的麻烦。不受广泛支持，尽管有些数据库允许这使得存储的proc处理更容易。

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

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用例中，这并不会对您有多大好处，因为没有资源管理器(即数据库或消息队列)支持它。

至于MVCC，这与事务管理器毫无关系。您的业务数据保存在资源管理器中，通常是关系数据库。RM用于提供tx隔离和并发控制的模型与事务的驱动方式是正交的。Oracle和postgres支持MVCC，而其他dbs则支持表、页或行级别的锁定。事务管理器不知道也不关心。

Answer 2

这个新闻组员额提到，到2010年为止，还没有计划支持Bitronix中的嵌套事务，而且它们似乎有点异国情调。

Atomikos TransactionsEssentials数据表将嵌套事务作为特性列出。

Answer 3

不仅JBoss支持嵌套事务:Atomikos也支持.嵌套事务对于经典(XA)事务没有多大用处，但对于先进的SOA事务模型(如Atomikos (尝试-确认/取消))来说是有用的。