ok, I understand now. The local lock ensures that only one thread gets access to the cache provider client, in case the cache provider client is not thread-safe. And the distributed cache lock ensures that no other NH client (in a farm of NH clients) changes or accesses the cache while a put or get is in progress.
So, if a cache provider client is thread safe, then the local lock could be removed. Because, as the code is now, if one thread is accessing one cache item, then no other threads can get access, even for different cache items. On Nov 11, 8:55 am, Fabio Maulo <[email protected]> wrote: > That is a matter that should be solved by the cache provider where > really needed. > > -- > Fabio Maulo > > El 11/11/2010, a las 10:00, Aaron Boxer <[email protected]> escribió: > > > Thanks, Fabio. I understand the need for locks, I am just wondering > > why there are two > > locks, the local lock and the cache lock, in the case of multiple > > clients and a distributed cache. > > > Certain cache providers, like memcached, do not provide locks, so you > > would need some other locking > > mechanism. For a farm of servers running the current version of NH, > > using memcached, > > with each server using a local lock, there wouldn't really be any > > locking across servers. > > Only locking for multiple threads on each server. > > > --Jorge > > > On Thu, Nov 11, 2010 at 6:06 AM, Fabio Maulo <[email protected]> wrote: > >> In web even a single app have to deal with multi threads > > >> -- > >> Fabio Maulo > > >> El 11/11/2010, a las 02:41, Jorge <[email protected]> escribió: > > >>> Hello! > >>> I was poring over the NH cache code, and was wondering about the > > >>> lock (_lockObject) > >>> { > >>> ... > >>> } > > >>> construct that is used in ReadWriteCache.cs when getting and putting > >>> values to the cache. > > >>> _lockObject is a local object, so it doesn't seem to make sense to > >>> lock > >>> on this for a cache shared among multiple NH clients. > > >>> Shouldn't it suffice to lock on the cache's distributed lock? > > >>> Another question: > > >>> put locks both _lockObject and the cache lock, but get only locks > >>> _lockObject, > >>> and does not lock the cache lock. It is commented out. Why is this? > > >>> Any insight into this would be very helpful. > > >>> Thanks!
