[wildfly-dev] What should the EJB3 StatefulSessionSynchronizationInterceptor.processInvocation() do for transactions that are already committed or rolled back

[Scott Marlow]

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 
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