Hi All,

In my view Firebird should continue to be designed such that it can
work satisfactorily without any configuration wizardry. Ideally, it
should work without any config whatsoever, all config should be
optional. To the best of my knowledge only Yaffil actually delivered that.

Now, there are a few different issues here.

[1] Linkage of lock file to a file system path

In my understanding FB only needs a named shared memory area. Why is
it mapped to a file system path? Just as a convenient uri? Or are
there other reasons?

[2] Unique id

The shared memory area needs a unique id, whether it is a path or not.
It needs to be determenistic, so that each classic instance can mmap
it in. The default could be something like FIREBIRD.ODSXXX.PORTNO, as
was already suggested in this list. Adding a port number makes it
easier to have multiple instances of the same provider on a single
piece of H/W.

[3] Easy fb_lock_print

Lock print needs to have access as well. It can be specified a lock
area name as an argument, in case the default is not enough. The ODS
number is in the lock area content, so it could take a peek and deal
with the right version. Newer fb_lock_print versions can analyse older
ODS versions, the reverse should gracefully fail.

fb_lockprint could for example use the newest ODS version and default
port number as default, so that a simple install works without any
hassle for a newbie user.

[4] Fool proof

I think we should try to at least generate a warning if a specific
setup has the potential to hurt data. Making it possible to have two
instances of a provider on the same box, using different lock files,
accessing the same db is perhaps not such a good idea.

It is another ODS change, but would it make sense to have to store the
name of the lock file used by the first instance accessing a db in the
header page, and blocking access using other lock files for instance
2, 3, etc.?

Paul