= m. Th = wrote:

> paulruizendaal wrote:
>
>> Slightly off-topic, but could I get back to per provider and per
>> database lock tables whilst we are on the topic of lock tables?
>>
>> I remember this was discussed at the end of a SAS session during the
>> 2005 Prague conference. My recollection of that discussion was that
>> Jim and Ann both thought that per database lock tables were a good
>> idea that had been considered in the past.
>>
>> Again in my recollection, Ann said that the reason for not doing per
>> database lock tables in the 80's was the limited supply of semaphores
>> on old Unices (16, or even 14, system-wide; these days 4096 is more
>> normal).
>>
>> Looking forward to hearing opinions about the benefit and feasibility
>> of per database lock tables.
>>
>> Paul
>>
> My first thought was to not post anymore on the theme, but if Paul
> continued it...
>
> Perhaps are silly things, but...
> 1. What was/is the design rationale to have one file / provider since,
> CIIW, the locks are database based?
>

So we could use the VMS distributed lock manager for VAXClusters.

There never has been a decision that different providers should use
different lock tables, though there is an issues that pre- and
post-Vulcan use different administration procedures.

> 2. Why do you use a file and not a memory space? IMHO, a lock table is
> (relatively) small and updated quite often so it can be a performance
> gain to store the things in the memory which (today) is cheap.
>

Lock file is a misnomer. The actual table is in shared memory. The
implementation is different on different operating systems, but it's
never accessed as file.