Subject | Re: [Firebird-Architect] Re: Vulcan architecture and lock tables |
---|---|
Author | Jim Starkey |
Post date | 2006-12-16T19:21:51Z |
Vlad Horsun wrote:
Seriously, detecting the case where two engines open the same file with
different lock files is well worth solving. I think a solution where
the first database file opener writes the same random number into the
database header and lock block header, then downgrades the file system
lock from exclusive to shared. Anyone who couldn't get an exclusive
lock on the file would check the header page against the lock table.
This would handle two non-classic engines from opening a database with
different lock files as well as the remote mounted database problem.
>> And Vulcan's config stuff can't prevent such problem too - we can open theHey, did it work?
>> same database via Firebird and via Vulcan simultaneously
>>
>
> And i did it.
>
> Are nobody worried about it ?
>
>
Seriously, detecting the case where two engines open the same file with
different lock files is well worth solving. I think a solution where
the first database file opener writes the same random number into the
database header and lock block header, then downgrades the file system
lock from exclusive to shared. Anyone who couldn't get an exclusive
lock on the file would check the header page against the lock table.
This would handle two non-classic engines from opening a database with
different lock files as well as the remote mounted database problem.