[Info-vax] RDB Question

[Arne Vajhøj]

On 12/4/2018 11:35 AM, Dave Froble wrote:
> On 12/4/2018 8:26 AM, Arne Vajhøj wrote:
>> On 12/3/2018 11:10 PM, Dave Froble wrote:
>>> On 12/3/2018 9:50 PM, Kerry Main wrote:
>>>> Also, Rdb supports row level locking which is a pretty big performance
>>>> feature that some DB's do not support.
>>>
>>> Why do we need different names for things.  Not that I've ever used
>>> Rdb, but, isn't that basically the same as a record lock?
>>
>> Yes.
>>
>>> And without that, I'm not sure I'd want to use a RDBMS ....
>>
>> It works without.
>>
>> Note that we are not talking  functionality of record locking
>> vs functionality of no locking.
>>
>> We are talking performance impact of database locking rows vs
>> performance impact of database locking pages.
>>
>> Both support the integrity of the database.
>>
>> But in some cases the performance is better if the
>> database can lock individual rows instead of locking
>> pages (8 KB or whatever chunks).
> 
> Well, as usual, mouth spoke before brain engaged.
> 
> Same old territory for me.
> 
> My database product does not actually lock records, it locks blocks, 
> based upon the size of the I/O buffer.
> 
> To actually lock records is a much tougher task, and might require 
> something like the numeric range locking that was discussed here a while 
> back.  This is something that I'm looking forward to in the future, when 
> persistent memory and updates in memory are implemented.  "Lock this 
> RECORD and do not impact any other operations."
> 
> Not being a HW type, I have no idea if there may be reasons to work on 
> whole pages rather than a range of bytes.  From a software perspective, 
> the "record lock" does appeal to me.

I think it is the same for RDBMS.

Page level only locking is easy to implement.

Having both page and row level available is convenient.

Arne