[Bug 198] New: LOCK_ISSUES_SHARED_LOCKS

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=198

           Summary: LOCK_ISSUES_SHARED_LOCKS
           Product: WebDAV-RFC2518-bis
           Version: -08
          Platform: Other
               URL: http://lists.w3.org/Archives/Public/w3c-dist-
                    auth/1999AprJun/0246.html
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: 06.  Locking
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
         QAContact: w3c-dist-auth@w3.org


Reported by Jason Crawford in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html>:

Shared locks... read locks... 
Our justifcation for shared locks ("Shared locks are included because....")
seems faulty. It's not a mechansim for dealing with programs that forget to
release their locks. That remains a problem with shared locks. In this case
they'd forget to release a shared lock and block exclusive lock users. Timeouts
and administrative action are the solutions to this problem... not shared locks. 
BTW, I'd think that the use of exclusive locks is just fine. I do have a problem
with shared locks though... or at least shared write locks. Although they were
relatively easy to define, I see them as solving a red herring problem of
multiple entites cooperatively writing using distinct locks. I say it's a red
herring because they don't know each other well enough to use the same lock but
they do know each other well enough to not step on each other. This seems
unlikely. As does the managing a compatibility matrix and getting all the
entities to abide by it. 
OTOH I see another more common problem that is being overlooked. I see a class
of folks whose purpose is to not actually write to a (set of) resource(s), but
to simply prevent others from writing to it while they are looking at it. Shared
write locks do not necessarily do that because with a shared write lock. someone
else could grab a shared lock and go ahead and write. The only way to block that
is to get an exclusive write lock. But doing that prevents anyone else from
doing what you're doing despite it being pretty benign. 
An expedient solution is to say that a shared write lock should not necessarily
give one the right to modify a resource. All it should do is prevent others from
writing. And then the purpose of an exclusive write lock is just to insure that
others can't get a lock and block you from writing. Now is this the right
solution? Probably not. There probably should be something called a read lock
that actually prevents writes as a side effect.... and would tend to get used in
shared mode. 
Anyway, as it is, I think the shared write locks are a red herring and we're
missing something we are more likely to need... shared read locks.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Monday, 21 November 2005 17:33:41 UTC