On 08/13/2014 03:07 PM, Scott Marlow wrote: > I created WFLY-3731 for a "No transaction is running" ISE [1], that is > thrown when > org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation() > checks if the current transaction is not null and not STATUS_COMMITTED. > > One obvious fix for WFLY-3731, would be to change > StatefulSessionSynchronizationInterceptor.processInvocation() to also > check for STATUS_ROLLEDBACK which would help my current case. Doing so Checking for STATUS_ROLLEDBACK, helps my test case somewhat. I am still seeing the below mention (WFLY-3730) JPA container failure as a result of the transaction status changing from active, to rolled back, after I called transaction.getStatus() (which returned STATUS_ACTIVE). I'm not quite sure what to do with the "IllegalStateException" that is thrown in either case (EJB or JPA container), since the transaction status can change after StatefulSessionSynchronizationInterceptor checks the status (e.g. in the transaction time out case that my testing is purposely hitting). The other related issue that I'm looking at, is how to better handle transaction time out (to avoid unexpected state or error conditions). I think that we might be missing an opportunity to coordinate the actions that occur when a background thread rolls back a transaction. > might defer clearing the transaction from the current thread, until we > later reached EJB container code (not really sure though, if we will > clear the ended tx). > > But, what does it mean exactly for > StatefulSessionSynchronizationInterceptor.processInvocation() to see an > ended transaction? Seems to me that we missed our chance to register > the StatefulSessionSynchronization, so we won't run the > StatefulSessionSynchronization.beforeCompletion() and > StatefulSessionSynchronization.afterCompletion() methods which I think > skips other logic (beforeCompletionMethod/afterCompletionMethod). > > Currently, it looks like we just continue with the invocation as if > there is no current transaction (SFSB level lock appears to be released > after the invocation instead of after the transaction ends). Which > makes some sense since the transaction already ended. > > When running the test case [2], I also see a JPA (EE) container level > failure as well which is reported as WFLY-3730. > > Scott > > [1] http://fpaste.org/125252 show the exception that I see when the > transaction times out in a background (tm reaper) thread. > > [2] test case is pushed to > https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> > Checking for STATUS_ROLLEDBACK, helps my test case somewhat. I am still > seeing the below mention (WFLY-3730) JPA container failure as a result > of the transaction status changing from active, to rolled back, after I > called transaction.getStatus() (which returned STATUS_ACTIVE). > > I'm not quite sure what to do with the "IllegalStateException" that is > thrown in either case (EJB or JPA container), since the transaction > status can change after StatefulSessionSynchronizationInterceptor checks > the status (e.g. in the transaction time out case that my testing is > purposely hitting). That is a massive edge case and there is not really anything that can be done about it, all you could really do is catch the exception and log it at debug. Stuart