[jboss-jira] [JBoss JIRA] Closed: (JBAS-5189) Txn-Manager arjuna commits data after timeout in long transactions

[Adrian Brock (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-5189?page=all ]

Adrian Brock closed JBAS-5189.
------------------------------

    Fix Version/s: JBossAS-4.2.3.GA
       Resolution: Done

Closing issue that was fixed a while ago.

> Txn-Manager arjuna commits data after timeout in long transactions
> ------------------------------------------------------------------
>
>                 Key: JBAS-5189
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5189
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.2.0.GA
>            Reporter: R??diger Schmitz
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.2.3.GA
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira