paulruizendaal wrote:

> 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.
>

Flexibility requires configuration control. User authentication in
Vulcan, for example, can be none (embedded), per database, per specific
authentication databases, or per server. Different users will pick
different solutions for good reasons. Should the client dispatch probe
for embedded access? The Interbase gateway? The Firebird 1.0 gateway?
Again, different users will have legitimate reasons for different
choices. Can we come up with a single hardwired default policy that
satisfies the needs of more than 5% of the users? I doubt it very
much. And if not, we have to deal with configurations.

Given that we have to deal with configurations, the questions are how to
make them sufficiently powerful to address the issues while minimally
intrusive so most users won't need to know that they're there.

The system I came up made provision for cascading personal, group,
system, product configuration files. The personal, group, and system
files are intended to be untouched by installations. The product
configuration files, in turn, are intended to be changed at installation
time to reflect installation options.

> 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?
>

The System V shared memory and semaphore systems use system wide ids,
but don't provide a direct mechanism for managing the ids. Most systems
use calls that map dummy files into ids that are sufficiently unique to
work. The problem is that direct management of the ids conflicts with
this convention, so we're probably stuck with it.

> [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.
>

The lock table format has nothing to do with the ODS or individual
databases or port numbers. It does have a format number (lhb_version)
in header. fb_lock_print either knows about the format or it doesn't.

> [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.
>

Nothing should hurt data, irresponsible claims to the contrary. Two
lock managers requiring different formats attempting to share a single
lock table will be detected by the following code:

if (LOCK_version != LHB_VERSION)
{
JString bugBuffer;
bugBuffer.Format("inconsistent lock table version number; found
%d, expected %d",
LOCK_version, LHB_VERSION);
bug(status_vector, bugBuffer);

return NULL;
}

(See LockMgr::create_owner for details).

> 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, ODS is an acronym to "on-disk structure". Databases live in disk
files and have on-disk structures. The lock table is created on first
reference and lives only until the last reference goes away. Databases
of different ODS version can be accessed by engines using a common lock
manager / format. The same database can be accessed (serially, however)
by two different engines using different lock managers / formats. In
short, they have nothing at all to do with each other.