当前位置：文江博客话题详情

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

发布于 2024-12-08 12:44:39 字数 324 浏览 1 评论 0原文

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

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

我知道 JBossTS 支持 MVCC 和 NT - 但我不确定 JBoss 是否是一个不错的选择，因为 JBoss 的使用带来了巨大的开销……特别是对于 Spring 和 hibernate 的用户。

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夏雨凉 2024-12-15 12:44:39

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

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

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

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.

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.

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.

回复收藏 0 原文