2

So in a project I'm working on I've got a Seam component that gets triggered by a TimerService and executes a method to update some data. This method usually runs a few seconds, but sometimes it may take a few minutes.

My problem is that if this method takes too long, the Arjuna TransactionReaper kicks in and kills the component. The default timeout is set to 5 minutes, which is sufficient for all the other components and I'd prefer not to change it.

Here is some simplyfied bits of my code:

@Name("myComp")
@Stateful(mappedName = "myComp")
@Scope(APPLICATION)
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionTimeout(timeout = 3600) //own implementation, used by Transaction class, see below
public class MyComp implements MyCompLocal
{
    @Override
    public void update() {/*...*/}
}

Somewhere here on StackOverflow (I fail to find the exact question that contained this, otherwise I'd link to it) I found a solution, that did sound good: Overwrite Seams Transaction class and set the timeout on the UserTransaction, so I did this:

@Name("org.jboss.seam.transaction.transaction")
@Scope(ScopeType.EVENT)
@Install(precedence=APPLICATION)
@BypassInterceptors
public class Transaction extends org.jboss.seam.transaction.Transaction
{
    @Override
    protected UserTransaction getUserTransaction() throws NamingException
    {
        UserTransaction ut = super.getUserTransaction();
        ut.setTransactionTimeout(getTimeout()); //getTimeout() uses the value set by the TransactionTimeout annotation, done by analyzing the stacktrace and reflection
        return ut;
    }
}

This actually seemed to work in the sense that the code is called and the timeout is set on the UserTransaction. Problem however is that Arjuna doesn't seem to care about this, I'm still getting:

WARN  [arjuna] ARJUNA-12117 TransactionReaper::check timeout for TX 0:ffffc0a88364:126a:53eb7613:8a in state  RUN
WARN  [arjuna] ARJUNA-12095 Abort of action id 0:ffffc0a88364:126a:53eb7613:8a invoked while multiple threads active within it.
WARN  [arjuna] ARJUNA-12108 CheckedAction::check - atomic action 0:ffffc0a88364:126a:53eb7613:8a aborting with 1 threads active!
WARN  [arjuna] ARJUNA-12121 TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,jboss] successfully canceled TX 0:ffffc0a88364:126a:53eb7613:8a
WARN  [arjuna] ARJUNA-12117 TransactionReaper::check timeout for TX 0:ffffc0a88364:126a:53eb7613:8b in state  RUN
WARN  [arjuna] ARJUNA-12095 Abort of action id 0:ffffc0a88364:126a:53eb7613:8b invoked while multiple threads active within it.
WARN  [arjuna] ARJUNA-12108 CheckedAction::check - atomic action 0:ffffc0a88364:126a:53eb7613:8b aborting with 1 threads active!
WARN  [arjuna] ARJUNA-12121 TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,jboss] successfully canceled TX 0:ffffc0a88364:126a:53eb7613:8b

after exactly five minutes after the method has been called. So it seems like Arjuna doesn't care about the timeout setting on the UserTransaction, at all. Any hints where I may look into to be able to fix this?

Btw.: JBossAS 6.1.0.Final, jdk_1.7.0_13, JBossTS 4.14.0.Final, Seam 2.2.2.Final

xor_eq
  • 3,933
  • 1
  • 29
  • 33
  • Hi!, do you find out a sollution? I've got a very similar problem: http://stackoverflow.com/questions/28992996/multithreading-transaction-hanging-during-persisting-entity-to-postgresql-via-wi – Marcin Erbel Mar 15 '15 at 10:01
  • No, sadly I didn't. What I did so far was implementing a few workarounds which resulted in smaller calls and in one case I acutally implemented an internal timeout where I basically stop the computation before Arjuna is able to kick in. This works in my case since I'm basically working on ping calls from external systems and nothing bad happens if a few of those are dropped in some runs. Still, it's ugly and I'd like to get rid of it. – xor_eq Mar 17 '15 at 15:57
  • Maybe my answer will help you. I dindn't know that my problem with hanging transactions was connected with log4j: http://stackoverflow.com/questions/28992996/multithreading-transactions-hanging-during-persisting-entity-to-postgresql-via-w – Marcin Erbel Mar 18 '15 at 08:14

1 Answers1

0

You can't set the timeout per resource manager (if that is what you are trying to do) but you can set it per transaction (before UserTransaction.begin is called)

  • I should say that you would need to call setTransactionTimeout again to reset it to 5 minutes after you complete the first one – tomjenkinson Jan 02 '19 at 14:34