> > > > 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 ?
Yes, what I meant was that cache operations must be mutexed, and preferably
by simly using the cache itself as a mutex. The mutex is only for
retrieving/working with the cache, not during the actual invocation of the
bean!!!
> > 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.
Then it makes even less sense to me. Why not mutex on the cache itself?
> 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).
Yes.
> > Local mutexes can be circumvented by backdoors.
>
> Backdoors ?
Let's say the interceptor plays nice and uses the mutex and all is well. But
some other code wishing to use the cache may not be so nice, and things
break. By using the cache as mutex you make it impossible to do such
"backdoors", i.e. using the cache when it really should not be possible to
do so.
Clear?
/Rickard
