RE: range locks vs. section locks

I should tread carefully as I am no expert on OLE documents (docobjs).
However, as I have come to understand it, the way we handle the whole
issue of byte range locking is by allowing IStreams to have pointers.
The idea is that the program happily writes away in a section of the
document when all of a sudden it finds that the next linear portion of
the document has already been written to or locked. The program will
insert a pointer to free space and then continue writing there. Every
once in awhile the system will save out the whole file and thus defrag
it. The motivation for this behavior was performance, having to move
things around in a file is really expensive. It is a lot easier to just
stick in a pointer.

So now we have two major real world scenarios, fixed length record based
documents (a.k.a. databases) and complex documents.

		Yaron

>-----Original Message-----
>From:	Steve Carter [SMTP:SRCarter@novell.com]
>Sent:	Friday, February 21, 1997 11:43 AM
>To:	Mark_Day/CAM/Lotus@lotus.com; w3c-dist-auth@w3.org
>Subject:	Re: range locks vs. section locks
>
>I'm suprised that some people think that the reason that I've supported range
>locking
>is because GroupWise uses the feature, GroupWise does not. In the early days
>SoftSolutions did, but that is behind us. Basically, range locking is a
>useful method
>for implementing a fixed-length record store that provides the necessary
>functionality
>for small to medium document management systems (whether they do versioning
>or not).
>Some editing systems that use range locking do so because they access a
>fixed-length
>index of the document structure that provides all access to the document
>body. Range
>locking is used here to protect the specific portion of the document. In both
>cases
>you do not see the byte count changing except at the end of the fixed-length
>portion of 
>the document or the DMS control file. Having been there, I suspect that there
>are
>systems out there that use range locking to provide this type of
>functionality.
>
>So now I'll put on my Novell hat. No, I don't need range locking. But I think
>we're being
>short sighted if we think that functionality such as range locking has no
>value to DAV.
>
>-src
>
>>>> <Mark_Day/CAM/Lotus@lotus.com> 02/21/97 08:54AM >>>
>
>I agree with Larry that it makes more sense in most cases to talk about
>section locks for the scenario of multiple authors wanting to manipulate
>different parts of the document. If your locks are on byte ranges, then the
>semantics (as I understand them) seem pretty unpleasant:
>
>1. In the simplest approach, you can't change the size of the locked range
>unless you lock from the start of the range to the end of the document
>(thus effectively locking most of the document if what you're modifying is
>near the beginning of the document).
>
>2. In a more complex approach, you can't safely re-lock a range using the
>same start & end points once you release the lock, because the actual byte
>numbering of that content in the document may have changed as others have
>inserted or deleted bytes from their ranges.  Section locking also has this
>problem, but in a milder form: the problem arises as sections are added and
>removed, which one would expect to be much less common than adding and
>removing bytes.
>
>People who have more experience with byte-locking systems should feel free
>to correct me on these points if I have misunderstood.
>
>--Mark
>
>
> 
>

Received on Friday, 21 February 1997 23:12:07 UTC