We encountered the following situation: Within an ejb using hibernate (and it's JTA transaction manager) we execute a long transaction. When the transaction run-time exceeds the arjuna timeout, the container outputs the following message:
> Abort of action id -5ea551d8:b05:47a18b1f:2f invoked while multiple threads active within it
> CheckedAction::check - atomic action -5ea551d8:b05:47a18b1f:2f aborting with 1 threads active!
After this, all following operations are directly committed to the database!
So, basically we have two problems:

• The timeout of the txn-manager triggers, even while the current database transaction is in continuous heavy use (numerous inserts/selects per second)
• Instead of aborting with an exception at once, the transaction manager happily carries on accepting data
• The data sent to the database before the timeout is discard
• The data sent to the database after the timeout is committed to the database. This results in inconsistent data within the database
• After the ejb-method commits an exception is thrown, leaving the database in an inconsistent state.
  A workaround is of course to increase the transaction manager timeout, but this defeats the purpose of the timeout. Furthermore, the duration of a transaction cannot always be estimated.