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

-----Original Message-----
From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Dmitry Yemanov
Sent: Friday, December 15, 2006 3:48 PM
To: firebird-architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Vulcan architecture and lock tables

Jim Starkey wrote:

>
> If I remember correctly, the name of the lock file can be specified in

> the configuration for each engine provider, which should handle the
> problem quite nicely.

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. And if you just put an
older provider into your setup (or if you upgrade your previous setup in
place), then you're in big trouble.

I have no problems with this feature for developers and/or experienced
field testers, but I would not suggest it for end users. Ever.


Dmitry



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.