Re: [Firebird-devel] crypt plugins

[Jim S. <ja...@ne...>]

Alex Peshkov wrote:

> Hi!
> Jim Starkey wrote:
>
>> If you have a solution you will save dozens of users from opening 
>> database with different path names, getting different lock tables, 
>> and trashing their databases.  If you've got a fix, the lock manager 
>> needs it.
>>
> Yes, I have a solution.
> But I need some advice. The real problem is between filename expansion 
> and y-valve. Remote susbsystem absolutely correctly maps local name 
> (like x:\dir\db.fdb) to full remote name 
> (\\ouserver\!favorite_share!\dir\db.fdb) and tries to invoke our own 
> server WNet listener. But it may be configured not to listen to WNet! 
> Or some other error happens (in my case I have 2 firebirds running on 
> same box - production and development, dev uses port 3060 and doesn't 
> accept WNet and local connections. They are separated also by 
> DatabaseAccess in firebird.conf not to have access to same databases). 
> Therefore remote reports error and y-valve passes x:\dir\db.fdb to 
> local susbsytem to process. ISC_expand_filename() doesn't check for 
> remote drive and opens database like local.
>
> It's easy to learn ISC_expand_filename() to check for remote mounts. 
> But it's used in many places of engine and not everywhere (external 
> table is example) this will be good. Now my ISC_expand_filename() 
> expands mount points only when called from y-valve (additional 
> parameter added). Does such approach seem correct to you?
>
> Another variant - change y-valve. May be it's worth learn him to 
> distinguish between "no, that's not my database" answer and "this is 
> my database, but failure happened opening it - don't try anymore". But 
> here your advice is much more needed.
>
The problem is when the same filesystem is accessable both through a 
local disk and remote mount.  As far as I know, ISC_expand_file doesn't 
handle this.

I know you're thinking in term of 2.0, but perhaps before suggesting 
changes you might take at look how the Vulcan Y-valve works, 
particularly with regard to it's relationship with the configuration 
file.  But to answer you question, it isn't (and never was) the 
Y-valve's job to pick a provider.  It doesn't (and shouldn't) have the 
knowledge to do this.  The Y-valve's job to poll subsystem to see if 
they can handle the connection.  Exactly how the providers accomplish 
this task is an internal issue to the provider and none of the Y-valve's 
business.  And if it isn't the Y-valve's job to know who a database 
belongs to, it is even less the job of a provider to tell the Y-valve to 
stop polling other providers.

The purpose of the architecture is draw clear lines of responsibilty 
between the components.  If done well, everybody's job is simpler and 
the pieces play well together.  And if not, you have a mess.

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376