JBAS-2668 EntitySynchronizationInterceptor

ben.wang Feb 4, 2006 7:41 AM

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 Feb 4, 2006 8:33 AM (in response to ben.wang)
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". :-)
Actions
2. Re: JBAS-2668 EntitySynchronizationInterceptor

adrian.brock Feb 4, 2006 10:23 AM (in response to ben.wang)

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

Go to original post