Paul O'Leary wrote:
>
> nissim,
>
> I reviewed the refreshing cache discussion from last week so I think I
> understand your issue a little better now.
> some clarification:
>
> you proposed implementing the refresh by extending the cache clearing
> functionality - this is in clearCache(), right? looks to me like, strictly,
> clearCache should be synchronized along with getObject and addObject since
> you're protecting the same resource (essentially, the hashtable) in each
> case. Unfortunately, this would have the effect (in you implementation) of
> serializing access to the cache for all requests while any value is being
> refreshed, e.g. value 'A' is being refreshed, cache is blocked, another
> request comes in which wants value 'B', it gets to wait until the database
> access to retreive 'A' is done. Not desireable. Would probably be safe,
> though. We could cook up a scheme that would work better, though, but'd be
> more complicated.
Would synchronizing on the cache Hashtable itself--rather than the
entire method--provide the same protection? That would reduce the scope
of the synchronization, thus reducing wait times.
> Or are you concerned with the case where a user calls getObject from outside
> the service, gets an exception because the value's not there then decides to
> add it themselves. This seems to be the case that Daniel is referring to.
> In this case I would agree that a race condition also occurs and it's
> probably outside the scope of the cache manager to address it.
That is exactly what I was referring to Paul, I just couldn't find the
right words to explain it. =)
> Whew. Threading issues can get so sweaty ;)
I'll say! Gotta protect those shared resources though...
--
Daniel Rall <[EMAIL PROTECTED]>
http://collab.net/ | open source | do the right thing
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
