[Info-vax] Integrated Databases

[Jan-Erik Söderholm]

Den 2018-05-30 kl. 20:12, skrev 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.

I cannot say I follow all details in this discussion. But I know that
Rdb can start with taking a lock on a larger range of buffers and then,
if there is a lock conflict, the lock will step down to smaller ranges
down to a single page or record. It is called "adjustable record locking".
Our current database has the defaults settings:

     Locking...
       - Adjustable record locking is enabled
           Fanout factor 1 is 10 (10 pages)
           Fanout factor 2 is 10 (100 pages)
           Fanout factor 3 is 10 (1000 pages)