|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!!!
if this is true for the passivation then the cache is OK, contention will be
low since it is just a "lock acquisition". However if there is
"passivation" in between then it makes no sense to do it this way (we lock
the lookup on a serialization to disk).
Simone, which one is it, if the first then Rickard's idea is the one to
implement, if the latter then we need something "like" what you did...
marc
|
|> > 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
|
|
|
|
