Re: [Firebird-devel] Configuring Firebird to run multiple servicesunder windows

[Vlad H. <hv...@us...>]

> Setting correct home directory is very important for firebird operation, cause here it keeps 
> various lock files, and the fact that only one firebird instance works with same set of lock 
> files at a time is absolutely required for it's successful operation. I repeat this well known 
> fact here to emphasize that starting more then one instance from same working directory 
> is a bug.

    Why ? It is dangerous to access same database by different engine instances using different
lock tables, yes. But we already discussed in fb-architect and agreed that we will add some 
number (or uuid) at lock table header and database header to avoid such conflicts.

> (There is a switch to set path to lock files separately from home, but this is not a full-featured 
> solution and requires more modifications in firebird be useful, cause code, working with security 
> database ignores that switch, and opening database from more then one instance of firebird 
> breaks it at once - and this is just the first sample which came to my mind.) 

    I don't think we need such switch. Lock table file can be created as now plus instance name. 
I not sure we must create distinct lock table for every distinct engine instance. And i not sure we can
identify embedded instances used shared file (in vulcan's terminology). Note - all instances used same 
lock table format can be served by only lock table. Ideally we may create shared memory regions not 
mapped to physical file thus we avoid need to setup path for lock table file. Just name this regions, 
say, 'FirebirdLockTable_' + <lock table format version number> (here we must also solve problem 
with access from different Windows sessions for applications without SeCreateGlobalPrivilege, but i 
leave it for now)

> Therefore currently we should better follow the rule of thumb - separate home for each instance. 

    Why ? Why i need to copy full installation just to run new instance ? Or i wrong understand what 
you said ? ;)

> But with that fact taken into an account, it becomes clear that adding any more switches to 
> command line is senseless and is just duplication - separate home directory contains separate 
> config file.

    Set config file name via cmdline switch is enough i think

> In the future it makes sense to have switches to set working directory (with security database, 
> lock files, may be specific UDFs) and home directory (with bin, lib, standard UDFs, etc) separately. 

    Why we ever need working directory if we know config file name ? And when home directory will
differ from directory with running binary ?

> But this is anyway not a reason to duplicate config file parameters in command line

    Agreed

Regards,
Vlad