> Something like this, perhaps:

No. This defaults to LOCK_FILE ("vulcan_lock1.%s"), when what I
suggested was "vulcan_lock1_ODS42-PROVIDER".
The problem mentioned was different providers fighting over the lock
file. Of course if the configuration source writes out a similar
default, that'll do the same thing. As you stated earlier, don't screw
with the file if you don't want to break it.
My suggestion was thrown out in case the provider doesn't provide a
customized configuration file.

-----Original Message-----
From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Jim Starkey
Sent: Friday, December 15, 2006 4:37 PM
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Vulcan architecture and lock tables

Rick Debay wrote:

>> It's the same as specifying the root directory per provider. It does
>>
> work if you get your hands dirty with the configuration. If you don't
> do it, your installation is irrecoverably damaged.
>
> Perhaps is a lock file is not specified, the file name defaults to a
> value specified by the provider. Instead of a file called <machine
> name>.lck, it would be <machine name><provider name>.lck or whatever
> convention you come up with. Deployers would be able to call the file

> <my lock name>.lck, specified in the configuration.
>
>

Something like this, perhaps:

JString lockFileName = configuration->getValue (LockFileName,
LockFileNameValue);

if (lockFileName.IsEmpty())
{
gds__prefix_lock(buffer, LOCK_FILE);
lock_file = buffer;
}
else
lock_file = lockFileName;

I did that way (two years ago) so it would work both with a proper
configuration and the pre-Vulcan Firebird conventions defined in
jrd/file_params.h.

Now, I don't want to be too preachy or anything, but did it occur to you
to look at what the code already did before making your suggestion?



Yahoo! Groups Links




Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.