[jboss-jira] [JBoss JIRA] Created: (JBRULES-2717) DroolsSpringJpaManager Creates Two Different Entity Managers Bound to the Same Thread

[Anatoly Polinsky (JIRA)]

DroolsSpringJpaManager Creates Two Different Entity Managers Bound to the Same Thread
-------------------------------------------------------------------------------------

                 Key: JBRULES-2717
                 URL: https://jira.jboss.org/browse/JBRULES-2717
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.1.1.FINAL
         Environment: N/A
            Reporter: Anatoly Polinsky
            Assignee: Mark Proctor


org.drools.container.spring.beans.persistence.DroolsSpringJpaManager

creates two DIFFERENT entity managers for the SAME thread:

ApplicationScoped ... = this.emf.createEntityManager();
CommandScoped ... = this.emf.createEntityManager();

I am sure there should be a good reason for it [ not sure what it is though, since it is not documented ], but... It breaks drools-flow clients if they already came with "their own" entity manager.

ApplicationScoped code is smart enough to check if there is already an entity manager factory bound to thread:

            EntityManagerHolder emHolder = ( EntityManagerHolder ) TransactionSynchronizationManager.getResource( this.emf );
            if ...
            emHolder.getEntityManager();

CommandScoped however is completely disrespectful to the thread, and only checks for its own key is in the ts manager:

            EntityManagerHolder emHolder = ( EntityManagerHolder ) TransactionSynchronizationManager.getResource( "cmdEM" );

So all processes end up with two different entity managers, which actually causes problems for the calling code that manipulates entities that are changed within the drools process ( optimistic locking: makes sense, since the version fields are changed by two entirely different entity managers )

Again, I am not sure what the whole purpose of this is, but we are using a RESOURCE_LOCAL transaction, and once I have "CommandScoped" change to follow the "TransactionSynchronizationManager.getResource( this.emf )" approach, the calling code works fine.

/Anatoly

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