From: Boris Z. (boris@conley.com)
Date: 08/14/98-08:12:39 PM Z
Message-ID: <01BDC7AF.203F8580.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: Locking questions Date: Fri, 14 Aug 1998 18:12:39 -0700 On Thursday, August 13, 1998 11:10 AM, Brent Callaghan [SMTP:Brent.Callaghan@Eng.Sun.COM] wrote: > > > The ``10.9. Locking and the new latency'' section mentions that > > read-locking can protect cached data on a client, but it's a puzzling > > protection. Would a client dare hold a read-lock for longer than > > necessary to protect its cache? How could it find out that a writer was > > trying to update the data? It seems to me that the server cannot just > > unilaterally deny LOCKX requests for a lock if a conflicting lock had > > been denied. This model would work OK for if the original lock were > > just being held to protect a data cache, but it would seem imprudent if > > the original lock were being held because an application had explicitly > > obtained a mandatory lock. Should different locks be used for cacheing > > from the locks used for application state? > > Yes, David Robinson has also pointed out this dichotomy: a client that > uses a read lock to protect cached data will not be terribly upset if > the server denies a LOCKX, but if the lock is to protect a transaction > then the client process might be very upset if the lock (assured by the > local API) is snatched away with a denied LOCKX. > > One way to resolve this would be to extend LOCKX to provide a > mandatory lock extension with the expectation that the client > would use it only for locks imposed explicitly by the application > and the non-mandatory extension to be used for cache protection. > I agree we need another lock type. I cannot understand how non-mandatory locks can solve this. A client that relies on such lock needs to be notified that this lock is 'broken'. That exactly what was done with opportunistic locks. Also we should allow several clients keep the same data in their caches. Servers should notify all clients that hold such op-locks. b.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:08 AM Z CST