Subject Re: [Firebird-Architect] Re: Vulcan architecture and lock tables
Author = m. Th =
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?
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.

(But if the feature cost is high, perhaps you can delay it...)

hth,

m. th.