Proper way of suspending transaction after the timeout

[tomekadamski]

Lets suppose we are using remote client that is invoking stateful session bean A using iiop interface. Transactions in A are container managed.

So we have:

A a = lookupBean();

a.foo();

Now let's suppose that there was a timeout during foo invocation. Rollback exception is being catched but the transaction has been not suspended. After such situation there is still the ControlWrapper object associated with the thread on the server. As a result if later we are trying to perform the same operation once again we can face corba's NameNotFound exception during InterpositionClientRequestInterceptorImpl operation - the interceptor looks for the ControlWrapper - it can find it so it looks for the transaction but hence transaction is not present the error occurs. If we want to disassociate the transaction with the thread, we have to suspend the transaction using TransactionManager's suspend method - if transaction is suspended then indeed the ControlWrapper becomes dissassociated with thread and the next transactions work correctly. To my understanding we should take this into consideration during each bean invocation. What is a good practice of doing that?

[mmusgrov]

The timeout will mark the transaction as rollback only. When the foo () ejb invocation completes the ejb container will try to commit the transaction and receive the rollback exception. We do not change the association in this case because there was a different outcome from the intended commit and the caller may want to ask for the transaction status. I think the container should handle that and disassociate the context, perhaps smarlow could comment on that.

[tomjenkinson]

+1 - it would be dangerous to leave the transaction associated with the caller thread in case they did something like this unexpectedly.

tm.begin

call @Required

// timeout

call @Required

tm.commit

The second @Required would use a new transaction.

[smarlow]

Originally, the EJB container org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction() was calling tm.commit() for all status except ROLLEDBACK.  For ROLLEDBACK, we were calling tm.rollback.  This had the problem of leaving failed transactions associated with the thread.

In 2013, we addressed that and more recently, switched to calling tm.rollback() for ROLLEDBACK/ROLLING_BACK (previously we called tm.suspend).  For MARKED_ROLLBACK, we are also calling tm.rollback(). 

+1 for updating the container(s) to not leave ended transactions associated with the thread, as only the top level container knows when it is the correct time to clear the transaction.

[tomjenkinson]

I moved this to the WildFly discussions as it seems to pertain more to the behaviour of the application server.

[tomekadamski]

I have diagnosed this issue thoroughly and it turns out that it is not a problem in server behaviour as disassociating thread from the context is part of standard rollback behaviour which is currently implemented in CMTTxInterceptor. The problem was caused by two bugs in narayana and CMTTxInterceptor itself. I prepared two pull requests that fix this issue: AtomicTransaction equals fix by tadamski · Pull Request #1044 · jbosstm/narayana · GitHub and CMTTxInterceptor transaction comparison fix by tadamski · Pull Request #9112 · wildfly/wildfly · GitHub. I'm closing this topic and moving the discussion to github.

[tomjenkinson]

Thanks for the contribution!