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

[Stuart Douglas]

Scott Marlow wrote:
> 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).

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

>
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev