Atomikos vs. Bitronix vs. JBossTS - MVCC和嵌套事务 [英] Atomikos vs. Bitronix vs. JBossTS - MVCC and Nested Transactions

问题描述

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

I want to implement one of the former Transaction Manager. However, since I am still in the concept phase I would like to try all of these Transaction Manager. My criterias for the final choice are the ease of use, use of Tomcat, the adaptility and most of all the support of nested transactions AND MVCC.

我无法找到有关Bitronix和Atomikos可能支持后者标准的任何信息。

I was not able to find any Information about the possible support of the latter criteria for Bitronix and Atomikos.

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

I know that JBossTS supports MVCC and NT - but I'm not sure if JBoss would be a good choice regarding the massive overhead which the usage of JBoss brings with it ... especially regarding the user of Spring AND hibernate.

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

Do you know if Atomikos and/or Bitronix fits my criterias - or would it be better to implement my own TM?

推荐答案

您需要更清楚地定义您的要求。 '嵌套交易'含糊不清。这可能意味着暂停一个事务以便运行另一个事务，然后恢复第一个事务：

You need to more clearly define your requirements. 'Nested Transactions' is ambiguous. This can mean simply suspending one transaction in order to run another, then resuming the first:

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容器。

This is common where you need to perform some operation e.g. an audit log update, that is logically separate from the outer transaction. Any transaction manager will do this, although it's rare to write code that drives the TM so directly. Use an EJB container instead.

然后你就可以在这种情况下只需要伪嵌套来简化逻辑结构：

Then you have the case where you simply want pseudo nesting to make structuring the logic easier:

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

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

This looks attractive at first glance, but causes more hassle than it is worth when a nested rollback occurs. Not widely supported, although some databases allow this to make stored proc handling easier.

最后你有真正的嵌套事务，其中子事务从其父事务继承锁并传递它在完成时拥有对该父项的锁

Finally you have true nested transactions, in which the subtransaction inherits locks from its parent and passes its own locks to that parent on completion

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用例都有好处，因为没有资源管理器即数据库或消息队列支持它。

This is useful mainly for fault isolation - it's possible to rollback the subtransaction and do something else instead without causing any impact on the outer transaction. This is a very powerful transaction model. It's also tricky to implement - only JBossTS currently supports it. Not that it will do you much good in most Java EE use cases, as no resource manager i.e. database or message queue, supports it.

对于MVCC，这没什么完全依赖事务管理器。您的业​​务数据保存在资源管理器中，通常是关系数据库。 RM用于提供tx隔离和并发控制的模型与事务驱动的方式正交。 Oracle和postgres支持MVCC，而其他一些dbs则支持表，页或行级锁定。交易经理不知道或不关心。

As for MVCC, that's nothing to do with the transaction manager at all. Your business data is held in a resource manager, usually a relational database. The model that RM uses to provide tx isolation and concurrency control is orthogonal to the way the transaction is driven. Oracle and postgres favour MVCC whilst some other dbs favour table, page or row level locking. The transaction manager does not know or care.

这篇关于Atomikos vs. Bitronix vs. JBossTS - MVCC和嵌套事务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！