JBAS-2668 EntitySynchronizationInterceptor

[ben.wang]

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.

[adrian.brock]

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". :-)

[adrian.brock]

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 :-)