Atomikos vs. Bitronix vs. JBossTS - MVCC and Nested Transactions

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.

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

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.

Do you know if Atomikos and/or Bitronix fits my criterias - or would it be better to implement my own TM开发者_如何学C?

---

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.

---

This newsgroup post mentions that as of 2010 there were no plans to support nested transactions in Bitronix, and they do seem to be somewhat of an exotic requirement.

The Atomikos TransactionsEssentials datasheet lists nested transactions as a feature.

---

Not only JBoss supports nested transactions: so does Atomikos... Nested transactions are not that useful for classical (XA) transactions but they are for advanced SOA transaction models like Atomikos TCC (Try-Confirm/Cancel).