Hi!
> > can you justify in detail why the mutex for the locking? it
> > doubles the lookup times...
>
> Take Stateful Instance Int'r. You can't do
>
> EnterpriseContext ctx = container.getInstanceCache.get(id);
> synchronized (ctx) {...}
>
> since the ctx can be passivated between the 2 rows.
> It can be passivated because isLocked is false and the TX may not be set.
Exactly, which is why it used an outer synch based on the cache, which means
that no other cache operations can interfere with it. With a separate mutex
local to the interceptor other users of the cache (i.e the passivation) may
use it and hence get a inconsistent state. So, I for one would be much more
comfortable with using the cache itself as the mutex since it is the
ultimate gatekeeper. Local mutexes can be circumvented by backdoors.
Makes sense?
/Rickard
