- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: 1999年12月28日 00:22:00 -0500
- To: w3c-dist-auth@w3.org
- Message-Id: <9912280522.AA15294@tantalum>
What Jim says is all reasonable, but cannot currently be inferred from the working in 2518. I'd suggest this be added to the issues list. In particular, I think it is reasonable for 2518 to say that an exclusive lock for a given locktype MUST not coexist with another lock of that same locktype. This gives a reasonable minimal semantics to "exclusive", while letting additional locktype specific semantics to be defined. Cheers, Geoff From: Jim Whitehead <ejw@ics.uci.edu> > Did section 8.10.6 of 2518 meant to say that an exclusive > lock will fail if there already is a lock *of that locktype* on that > resource, or if there is *any* exclusive lock there? The intent was for the exclusivity to apply per locktype. So, for example, an exclusive read lock would not affect taking out an exclusive write lock. However, it is possible to imagine lock types that would have semantics that are not orthogonal to existing locks. For example, while read and write are pretty orthogonal, and hence exclusive read and exclusive write locks can co-exist happily on the same resource, a hypothetical "read/write" lock type would interfere with both a write lock and a (equally hypothetical) read lock, and in this case I would expect a request for an exclusive read/write lock to fail if there is either a shared read lock, or a shared write lock, or an exclusive read lock, or an exclusive write lock on the resource. So, the best answer is, when defining a new lock type the interactions of the new lock type with all existing lock types needs to be taken into consideration when creating the lock compatibility table.
Received on Tuesday, 28 December 1999 00:22:09 UTC