[#CORE-5185] Connection string: to have option demanding/prohibiting use of embedded (in-process) engine.

Firebird Core

Connection string: to have option demanding/prohibiting use of embedded (in-process) engine.

Created: 05/Apr/16 01:50 PM Updated: 06/Apr/16 11:06 AM

Component/s:

API / Client Library

Affects Version/s:

3.0 RC2

Fix Version/s:

None

QA Status:

No test

Description

« Hide

Using embedded (in-process) engine has a muber of cons and pros. It might easy the deployment, but it also provides for application crash destroying the database.

For FB 1.x and 2.x application developer could specify his intention by selecting client DLL/SO

Since FB3 there seems to be no separate client DLLs released for embedded and standalone servers.
Many develoeprs foreseeing transition to 3.x asked how to ensure one of those modes to find there is no standard way and they should bind their application to FB 3.0 implementation details instead.

A requirement to use standalone server to an extent can be manifested by specifying inet:// or wnet:// pseudo-URI. But not with local (net) connection string.
A requirement to use embedded server can not be manifested at all.

So to specify the connection method there is a need for standard options ( made as a pair of pseudo-URI or better a parameter ) for the connection string that would specify application's requirement to use either embedded server dll in its own process or a standalone (not-embedded, independent) server process.

By option being standard it is meant that it would be documented, would be forward-compatible (until breaking changes would become required should work with FB 4.x, 5.x, etc) and should not be dependent upon leaking implementation details ( specific dll names that are subject to change, presence or absence of dlls in FB installation, specific hacks in firebird.conf, etc).
It should be an option that applicaition can set in a standard predictable future-compatible way without making any assumptions about FB version (except being 3+) and installation details.

Of course connection strings like "inet://localhost:3052/c:\temp\db.fdb?isolation=in-process" would result as connection failure as tere is no plugin that would be both embedded and TCP-connecting. That is okay, explicit error it is better than hidden change in behavior.
Similarly "c:\temp\db.fdb?isolation=standalone" would most probably use xnet connection.
And mere "c:\temp\db.fdb" would leave the choice to the server's preferences and ability to lock database file by th application process.

PS. I hope that there would be 3.0.x or 3.x build that can implement this relatively isolated feature, as waiting two more years for 4.0 just to recover a minor connection-level feature from 2.x seems a bit long.

Description

Using embedded (in-process) engine has a muber of cons and pros. It might easy the deployment, but it also provides for application crash destroying the database. For FB 1.x and 2.x application developer could specify his intention by selecting client DLL/SO Since FB3 there seems to be no separate client DLLs released for embedded and standalone servers. Many develoeprs foreseeing transition to 3.x asked how to ensure one of those modes to find there is no standard way and they should bind their application to FB 3.0 implementation details instead. A requirement to use standalone server to an extent can be manifested by specifying inet:// or wnet:// pseudo-URI. But not with local (net) connection string. A requirement to use embedded server can not be manifested at all. So to specify the connection method there is a need for standard options ( made as a pair of pseudo-URI or better a parameter ) for the connection string that would specify application's requirement to use either embedded server dll in its own process or a standalone (not-embedded, independent) server process. By option being standard it is meant that it would be documented, would be forward-compatible (until breaking changes would become required should work with FB 4.x, 5.x, etc) and should not be dependent upon leaking implementation details ( specific dll names that are subject to change, presence or absence of dlls in FB installation, specific hacks in firebird.conf, etc). It should be an option that applicaition can set in a standard predictable future-compatible way without making any assumptions about FB version (except being 3+) and installation details. Of course connection strings like "inet://localhost:3052/c:\temp\db.fdb?isolation=in-process" would result as connection failure as tere is no plugin that would be both embedded and TCP-connecting. That is okay, explicit error it is better than hidden change in behavior. Similarly "c:\temp\db.fdb?isolation=standalone" would most probably use xnet connection. And mere "c:\temp\db.fdb" would leave the choice to the server's preferences and ability to lock database file by th application process. PS. I hope that there would be 3.0.x or 3.x build that can implement this relatively isolated feature, as waiting two more years for 4.0 just to recover a minor connection-level feature from 2.x seems a bit long.

Show »

All

Comments

Change History

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Alexander Peshkov added a comment - 05/Apr/16 02:05 PM

Being in general agree that a way to force use of embedded/server access is useful I want to point to the fact that with correctly administered access rights to database directory user who is not supposed to used embedded access (normally that's all users in case of SS except admins) should not have file access to databases at OS level and following this rule will solve most of your problems.

[ Permalink | « Hide ]

Alexander Peshkov added a comment - 05/Apr/16 02:07 PM

What about parameter - is appears extra complication. I would sooner think about net:// for any server access and file:// for embedded access.

[ Permalink | « Hide ]

Arioch added a comment - 06/Apr/16 11:06 AM

with xnet and local ipc being brought together under "net" umbrella...

possible

also there may be nested URIs like the one JayBird provides for OpenOffice.org

I was thinking that making those options ( specifying protocol by URI and specifying isolation ) orthogonal would provide for more flexibility, allowing any combination of those options (or lack of) to be coded. Though I do not know if that would add practical value or this added flexibility would remain purely hypothetical.

> with correctly administered access rights to database directory

In some situations bullet-proof admins for FB is not what we can expect form real users.

also it does not solve the reverse problem - "A requirement to use embedded server can not be manifested at all."

----

Then there is a question how to implement it in yvalve<->transport plugins interface.

With a special option - one may add a single function to plugins interfaces: "AreYouEmbedded?()".
Then if the option is specified in the CS/DPB the server when enumerating those plugins would just ad that call and filter plugins which gave result different from the provided option.

With meta-URI it seems less straightforward to me. It asks for the inverted approach with some in-server (hardcoded?) list which plugins belong to "net" subset and which - to "file". So new transport-layer plugins would need changes in that central directory instead of implementing self-description call.

----

From mere user point of view though umbrella URI schemes might work too. Just I do not like "file" and "net" names - they seem confusing to me, specifying where the file is situated instead of specifying how server should interact with an application. "embedded://" and "isolated://" would look better to me.