2 Replies Latest reply on Feb 4, 2006 10:23 AM by Adrian Brock

    JBAS-2668 EntitySynchronizationInterceptor

    Ben Wang Master

      While trying to fix JBAS-2668, I have broken the unit test EJBLoadTest:
      http://jira.jboss.com/jira/browse/JBAS-2745

      However, the problem to me lies not in my fix, rather it is the way that when under no tx and with commit option c, the codes tries to do a:
      container.getInstanceCache().release(ctx);
      in line 381. I think this is flawed because cache.release() tries to perform tryToPassivate to see if it can passivate the bean from the cache. But the real intention is to evict the bean from the cache such that it will be reloaded from the store.

      Therefore, I propose to fix it as:
      container.getInstanceCache().remove(ctx.getId());
      as in line 323 where its counterpart is under tx.

      Does anyone see any issue? This is just a simple bug fix but since it has more implication, I thought I ask it here.

        • 1. Re: JBAS-2668 EntitySynchronizationInterceptor
          Adrian Brock Master

          It already does that for the case of read-only in a transaction,
          which is pretty much the same case (no transaction synchronization).

          See the code earlier on:

           // FIXME: We cannot passivate here, because previous
           // interceptors work with the context, in particular
           // the re-entrance interceptor is doing lock counting
           // Just remove it from the cache
           if(ctx.getId() != null)
           container.getInstanceCache().remove(ctx.getId());
          


          The real solution should be to remove it from the cache
          and "schedule" passivation for when whoever is using it releases it.

          It used to do exactly that prior to 3.2.x (all passivation was on a background thread)
          but Bill "simplified it". :-)

          • 2. Re: JBAS-2668 EntitySynchronizationInterceptor
            Adrian Brock Master

            Or we should just add a big warning if somebody tries to use option-c with a shared instance
            cache. They should use the multiple instance config :-)