[Info-vax] Integrated Databases

[Dave Froble]

On 5/30/2018 1:17 PM, Stephen Hoffman wrote:
> On 2018-05-30 02:50:09 +0000, Dave Froble said:
>

>> Regardless, from what I read, it appears that there is still a need
>> for locking a range of bytes, which may span block boundaries, and may
>> not include whole blocks.  Now, as I see it, locking should be done by
>> the DLM.
>
> As mentioned above, cache coherence can involve locking, yes.
>
>> At this time, the DLM has one type of lock, a lock on a resource name.
>> My idea was to allow multiple types of locks.  A second type might
>> lock a numeric range, x to y.  Some part of the lock would be two 8
>> byte integers, and for that type additional code to determine if any
>> part of that range is already locked.
>
> Unclear.  Byte-range locking might provide an optimization around cache
> coordination, or it might not.
>
>> Once there are DLM types of locks, while I have no idea at this time
>> what a third type of lock might be, there is the option for additional
>> types of locks.  Sort of flexible, huh?
>
> I can see uses for byte-range locks, entirely separate from this
> particular SSIO case.

When I looked at this, it wasn't strictly as a fix for SSIO and 
PostgreSQL.  Being able to lock a numeric range is a basic concept that 
could be very useful.

As one example, back in the day when my DAS database was implemented, 
there was much concern about locking large blocks of data.  The product 
allowed a file to be opened for shared access with buffer sizes up to 
127 blocks.

While not suggested for use, the capability was included.  What we ended 
up doing was taking up as many locks as there would be blocks in the I/O 
buffer, which could be up to 127 for a single read.  With the problem of 
not getting any one of the 127 locks, having to release all locks, and 
start over.

Back then, it was normal to use one block I/O buffers, so from a 
practical standpoint, it wasn't much of an issue.  Large I/O buffers 
would be used when scanning a file, and opened read only so no block 
locks were required.

The point is, for that application, being able to take out one lock for 
all 127 blocks sure would have been a nice capability.  As you 
mentioned, there might be lots of uses for such a capability.

Note, I'm talking about a 1984 product which while still in use is 
totally inappropriate today for any new work.  I've been seduced by the 
capabilities and flexibility of relational databases.

Even without byte addressable mass storage, using a global section for 
access to some database would need locking capability unless data would 
be accessed in single blocks.  Multiple block accesses or byte range 
accesses would need some manner of locking.