[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2973) EjbSynchronisations are destroyed before afterCompletion call

[Pete Muir (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBSEAM-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBSEAM-2973:
------------------------------

    Fix Version/s: 2.1.0.BETA1


> EjbSynchronisations are destroyed before afterCompletion call
> -------------------------------------------------------------
>
>                 Key: JBSEAM-2973
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-2973
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.1.GA
>         Environment: JBOSS4.2.2GA
>            Reporter: stefan meyer
>             Fix For: 2.1.0.BETA1
>
>
> http://www.seamframework.org/Community/EjbSynchronisationsAfterCompletionNotCalled
> I use an MDB. The EJBSynchronisations.registerSynchronisation are called by MangedPersistenceContext and ManagedJbpmContext. Thus creating 3 Synchronisation-Registration on the UserTransaction (first once is created by creating the ejb or maybe calling the create-method - dont know exactly). At some point the EJBSychronisations will be destroyed since they are stateful. Seam destroys them when calling Lifecycle.endCall and destroying the Contexts. The destruction will create another TransactionSynchronisation implemented by the StatefulRemoveInterceptor from Jboss. The beforeCompletion will be called in the order the synchronisations were registered. The afterCompletion will be called in the reverse order. The StatefulRemoveInterceptor is first and removes the EjbYnchronisation from the cache (whatever that is). The other calls fail because the ejb container cannot find them.
> My ugly workaround is to force a different order calling create and destroy of EJBSynchronisations upon entering the MDB. This leads to only one failure - the very first Synchronisations. 
> Reproducing this problem should be very straight forward. Just call an MDB and do sonething with the seam managed entityManager.
> Another bug closely related is that ManagedPersistenceContext.afterCompletion calls close. and in close it unsuccessfully tries to get a hold of the transaction component (Transaction.instance) - the contexts are gone already.
> here is the critical code (Please see the comment in afterCompletion):
>    public void afterCompletion(int status)
>    {
>       synchronizationRegistered = false;
>       //if ( !Contexts.isConversationContextActive() )
>       if (destroyed)
>       {
>          //in calls to MDBs and remote calls to SBs, the 
>          //transaction doesn't commit until after contexts
>          //are destroyed, so wait until the transaction
>          //completes before closing the session
>          //on the other hand, if we still have an active
>          //conversation context, leave it open
>          close();
>       }
>    }
>    private void close()
>    {
>       boolean transactionActive = false;
>       try
>       {
>          transactionActive = Transaction.instance().isActive();
>       }
>       catch (SystemException se)
>       {
>          log.debug("could not get transaction status while destroying persistence context");
>       }
>       
>       if ( transactionActive )
>       {
>          throw new IllegalStateException("attempting to destroy the persistence context while an active transaction exists (try installing <transaction:ejb-transaction/>)");
>       }
>       
>       if ( log.isDebugEnabled() )
>       {
>          log.debug("destroying seam managed persistence context for persistence unit: " + persistenceUnitJndiName);
>       }
>       
>       if (entityManager!=null)
>       {
>          entityManager.close();
>       }
>    }
>    

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira