Hey,
> 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.
What do you mean exactly ?
While calling a bean I want to have another client to be able to create
beans and hence insert them in cache, correct ?
> 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.
The mutex is local to the cache, not to the int'r, so that the passivation
can sync on it.
> So, I for one
> would be much more
> comfortable with using the cache itself as the mutex since it is the
> ultimate gatekeeper.
It does not make so much difference, apart from the fact that (as Marc
pointed out) I save a hash table lookup. What you suggest (using the cache
as mutex) is probably the best solution (faster and equally safe).
> Local mutexes can be circumvented by backdoors.
Backdoors ?
Bye
Simon
