[Jboss 7.1.3] Error when invoking @Remove method for stateful bean in transaction

[kkkppp]

I'm invoking method, looking like this:

  @Remove

    public void remove() {

...

On invocation inside active transaction I'm getting error like this:

Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING

    at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:374)

    at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:351)

    at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:165) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:57) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:283) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:200) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]

    ... 140 more

AFAIK, I'm allowed to invoke methods, annotated by @Remove when stateful bean is enlisted in transaction, but probably I'm missing something.

[sfcoy]

The spec actually says:

{quote}The PostConstruct, PreDestroy, PrePassivate, PostActivate, Init, and/or ejbCreate<METHOD>, ejbRemove, ejbPassivate, and ejbActivate methods of a session bean with container-managed transaction demarcation execute with an unspecified transaction context.{quote}

So, the short answer is that the behaviour is undefined.

See §13.6.5 of the spec to see what this means in detail.

[kkkppp]

13.6.5 says

This includes the following cases:

...

•The execution of a PostConstruct, PreDestroy, PostActivate, or PrePassivate callback method of a session bean with container-managed transaction demarcation.[71]

But I was referring to 4.6.4 which seems more suitable for my case:

If a session bean instance is participating in a transaction, it is an error for a client to invoke the remove method on the session object’s home or component interface object. The container must detect such an attempt and throw the javax.ejb.RemoveException to the client. The container should not mark the client’s transaction for rollback, thus allowing the client to recover. Note that this restriction only applies to the remove method on the session object’s home or component interface, not to the invocation of @Remove methods.

[sfcoy]

The paragraph I quoted above comes from the last part of §4.6.1.

I had thought that ejbRemove methods and @Remove methods were the same thing, but the former is called by the container (and is synonymous with a @PreDestroy method), and the latter is called by application code.

It could be that this behaviour is a bug.

(I should really resist answering questions after midnight!)

[kkkppp]

So I'm not sure what is resolution of this? Is it a bug? If so, do I submit JIRA ticket for it?

[smarlow]

With regard to the actual error, I looked at the TransactionAwareObjectFactory code and am not sure why the TransactionSynchronizationRegistry isn't used.  We switched other parts of the AS7 codebase to use interposed synchronizations. Its likely that we are getting this error because we are ending the transaction and are trying to register the transaction (non-interposed) sync too late (after TX level SessionSynchronization beforeCompletion callbacks have already run).

From the javadoc for TransactionSynchronizationRegistry:

Register a Synchronization instance with special ordering semantics. Its beforeCompletion will be called after all
SessionSynchronization beforeCompletion callbacks and callbacks registered directly with the Transaction, 
but before the 2-phase commit process starts. Similarly, the afterCompletion callback will be called after 2-phase
commit completes but before any SessionSynchronization and Transaction afterCompletion callbacks.

If we switched TransactionAwareObjectFactory to use the TransactionSynchronizationRegistery to register its sync to be interposed also, the afterCompletion callback will be called after 2-phase commit completes but before any non-interposed  (Transaction level) afterCompletion callbacks.  I'm not sure if that would meet the requirements for TransactionAwareObjectFactory.  Probably need to hear from Paul about that.

I think that you need to enable TRACE logging for Arjuna and examine the server.log.  Some guidance on enabling TRACE logging is here.

For the part about whether your code is EE/EJB specification compliant, I didn't look into that.

[pferraro]

I'm having a little trouble reproducing this issue.  If I trigger a @Remove method within the context of a transaction I don't get any error.  Can you provide more context?

Scott, I don't think the issue is related to registering the transaction synchronization too late.  The stack trace above indicates the transaction is RUNNING, so I don't see any immediate reason why the synchronization registration should fail.  I'm digging through the arjuna code to find relevant conditions for failing synchronization registration, but it would be most helpful if I could reproduce the issue locally.

[smarlow]

https://issues.jboss.org/browse/JBTM-849 contains hints to decoding what the "Synchronizations are not allowed!" means.

It is thrown because the transaction is past the point of *invoking"  non-interposed synchronizations, so new transaction level synchronizations can't be registered (since they woudn't be called).

[pferraro]

I agree - TransactionAwareObjectFactory should use an interposed synchronization, since we want the cache removal to happen after any afterCompletion callabacks.  However, I still don't think this is the cause of the failure.  See my previous post.

[noelaa5]

Hi Paul,

I have the same problem here when migrating EJB2.1 from jboss5.1 to jboss7. I saw you had a problem reproducing the error.

So I wrote a sample scenario consisting of 3 small projects ( EAR, EJB and EJB Client).

To use the sample and reproduce the error, please follow these steps :

1- Download projects from http://www.filedropper.com/jbosstxsyncerror

The zip contains 3 projects

    JBossTxSyncError : EJB Project

    JBossTxSyncErrorClient : EJB Client Project

    JBossTxSyncErrorEar : Ear project

2- Import project into Eclipse   

3- add required libraries in build path

       JBossTxSyncError

             JBoss 7.1 Runtime

      JBossTxSyncErrorClient

              jboss-client.jar

              jboss-ejb-api_3.1_spec-1.0.2.Final.jar

4- create table using create.sql file under JBossTxSyncErrorClient

5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient

6- configure a datasource for mysql connection

7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi

8- deploy ear file and run OldEjbClient.java

Thanks for helping,

[kkkppp]

Were you able to reproduce error using the sample application above?

[gaol]

The link you send can't be accessed publicly, why not attach your sample applications to the associated jira issue if this still annoys you?