| Subject | Re: [firebird-support] Rules on embedded server? |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-07-18T23:47:52Z |
At 02:37 AM 19/07/2007, you wrote:
distinctly different concepts depending on whether you are talking
about the Windows implementation or the Posix one.
Windows Embedded is Superserver, a process that spawns threads for
its tasks. In the embedded model, the main process runs in the
user's application space and has the restriction that new threads can
be spawned only in that application space and only across the IPC
transport. This embedded server instance may involve several
threads, including multiple connections from within that
user/application context. (The server also uses threads for its own
background functions, such as garbage collection).
On Windows, the embedded server is making a normal database
connection for the client via the embedded client library, using a
normal (for Windows) emulated network transport (IPC).
On Windows, Superserver imposes a read/write lock on the database
file as soon as the first connection is made. This applies whether
the full SS is used, or the embedded version. The purpose of this
lock is to prevent a database-corrupting situation that can occur due
to the fact that Windows allows alternative formats for file paths.
On Linux, there is no "embedded" option for Superserver. To achieve
embeddedness on Linux you use the library libfbembed.so, which is a
single instance of Classic with a client that is capable of
connecting directly to a database *file*, i.e. there is no network
transport involved. Your connection string omits any hostname
element. The client code in libfbembed.so is *not* thread-safe.
You *can* use the client element of either the Windows embedded or
the Linux libfbembed.so as a regular network client. So, if you
include a hostname in the path on Linux Classic, you will go via the
xinetd daemon, which creates an instance of fb_inet_server - and the
connection is across the network transport in the server's user
space. Then, it is not embedded.
the database file ("embedded"), No. (Hint: you can use
libfbclient.so with Classic for multi-threaded client apps...but it's
not embedded, of course.)
application's folder structure. This is documented in detail in the
release notes of both Fb 1.5 and Fb 2.0.x.
For Linux, it is just a normal Classic install.
The Windows version bypasses server authentication altogether, so you
don't need to install the security database. On Linux, you need to
keep the installation structure intact because an embedded connection
*does* require server authentication.
In both cases you still need to pass a user name to the connection if
your database is using SQL privileges (as it should). The user
credentials in the security database are not linked to user names in
the SQL privileges in databases. For server models that require user
authentication, obviously the user names in both databases need to
match. For Windows embedded, it doesn't matter - the user names in
the user database privs can be anything.
file in either case, although for different reasons. On Windows you
have the protective read/write lock that is exclusive to the
Superserver *process*. On Linux you have the exclusive read/write
lock that prevents anything else from getting access to the file
whilst the embedded application has it.
were explicitly documented in a holistic way -- and that could (and
will be) done better, with knowledge and experience gained since
2004. But the Firebird release notes are pretty explicit about what
you need to do for the Windows embedded model. There are highly
plausible reasons for the lack of "public" documentation, not the
least among which is the sorry lack of Firebird consumers who are
willing to make the effort and help with documentation.
Historically, though, there was no distinction between "embedded" and
"client/server" in the Borland documentation. On Linux there was
what we now call "Classic", that had the option to use "the client"
(libgds.so, what Firebird now calls libfbembed.so) with the embedded
server code and direct connection or as a network client (via
[x]inet), while on Windows there was Superserver and nothing else.
Over time, Firebird has extended the options so that on Linux we have
SS and a network-only client (libfbclient.dll) that can also be used
to connect to fb_inet_server; we have Classic on Windows (via
network transport only in v.1.5 and able to use IPC in v.2 + ); and
we have an implementation of Superserver on Windows that is capable
of providing embedded capability. Documentation of these advances is
all too scarce...but you would serve yourself well to visit the
Documentation Index and pull up some of the informative papers that
have been written and/or updated by Paul Vinkenoog and others during
the Firebird era.
./heLen
>I haven't been able to get a clear picture on the rules for embeddedFirst you have to understand that the "embedded" label refers to 2
>database use on Linux and Windows. Can someone answer:
distinctly different concepts depending on whether you are talking
about the Windows implementation or the Posix one.
Windows Embedded is Superserver, a process that spawns threads for
its tasks. In the embedded model, the main process runs in the
user's application space and has the restriction that new threads can
be spawned only in that application space and only across the IPC
transport. This embedded server instance may involve several
threads, including multiple connections from within that
user/application context. (The server also uses threads for its own
background functions, such as garbage collection).
On Windows, the embedded server is making a normal database
connection for the client via the embedded client library, using a
normal (for Windows) emulated network transport (IPC).
On Windows, Superserver imposes a read/write lock on the database
file as soon as the first connection is made. This applies whether
the full SS is used, or the embedded version. The purpose of this
lock is to prevent a database-corrupting situation that can occur due
to the fact that Windows allows alternative formats for file paths.
On Linux, there is no "embedded" option for Superserver. To achieve
embeddedness on Linux you use the library libfbembed.so, which is a
single instance of Classic with a client that is capable of
connecting directly to a database *file*, i.e. there is no network
transport involved. Your connection string omits any hostname
element. The client code in libfbembed.so is *not* thread-safe.
You *can* use the client element of either the Windows embedded or
the Linux libfbembed.so as a regular network client. So, if you
include a hostname in the path on Linux Classic, you will go via the
xinetd daemon, which creates an instance of fb_inet_server - and the
connection is across the network transport in the server's user
space. Then, it is not embedded.
>1. Can multiple threads in an application each make their own connectionWindows Yes. With libfbembed.so on Linux and a direct connection to
>to a local database using embedded Firebird or can only one thread do
>this? Same with Windows and Linux?
the database file ("embedded"), No. (Hint: you can use
libfbclient.so with Classic for multi-threaded client apps...but it's
not embedded, of course.)
>2. Can external programs also make a connection to the database while inNo.
>use by the application? Same with Windows and Linux?
>3. What files need to be included when installing Firebird embedded withFor Windows, the embedded client has to be properly located in the
>Linux and Windows?
application's folder structure. This is documented in detail in the
release notes of both Fb 1.5 and Fb 2.0.x.
For Linux, it is just a normal Classic install.
The Windows version bypasses server authentication altogether, so you
don't need to install the security database. On Linux, you need to
keep the installation structure intact because an embedded connection
*does* require server authentication.
In both cases you still need to pass a user name to the connection if
your database is using SQL privileges (as it should). The user
credentials in the security database are not linked to user names in
the SQL privileges in databases. For server models that require user
authentication, obviously the user names in both databases need to
match. For Windows embedded, it doesn't matter - the user names in
the user database privs can be anything.
>Ideally what I want is to use embedded Firebird on Linux and Windows byAny other application will be blocked from accessing the database
>just including a small number of runtime files (shared library or DLL
>and perhaps the messages and a security database?) and I'd like for
>multiple threads in my server to each be able to have their own
>connection to the database. Its fine if external tools can't work with
>the database while my threaded server application is working with it but
>it would be a bonus if they could somehow.
file in either case, although for different reasons. On Windows you
have the protective read/write lock that is exclusive to the
Superserver *process*. On Linux you have the exclusive read/write
lock that prevents anything else from getting access to the file
whilst the embedded application has it.
>Thanks for any clarification on this or pointing me to a source of theI think my book was the first place the cross-platform differences
>info needed!
were explicitly documented in a holistic way -- and that could (and
will be) done better, with knowledge and experience gained since
2004. But the Firebird release notes are pretty explicit about what
you need to do for the Windows embedded model. There are highly
plausible reasons for the lack of "public" documentation, not the
least among which is the sorry lack of Firebird consumers who are
willing to make the effort and help with documentation.
Historically, though, there was no distinction between "embedded" and
"client/server" in the Borland documentation. On Linux there was
what we now call "Classic", that had the option to use "the client"
(libgds.so, what Firebird now calls libfbembed.so) with the embedded
server code and direct connection or as a network client (via
[x]inet), while on Windows there was Superserver and nothing else.
Over time, Firebird has extended the options so that on Linux we have
SS and a network-only client (libfbclient.dll) that can also be used
to connect to fb_inet_server; we have Classic on Windows (via
network transport only in v.1.5 and able to use IPC in v.2 + ); and
we have an implementation of Superserver on Windows that is capable
of providing embedded capability. Documentation of these advances is
all too scarce...but you would serve yourself well to visit the
Documentation Index and pull up some of the informative papers that
have been written and/or updated by Paul Vinkenoog and others during
the Firebird era.
./heLen
>--
>Brad
>
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Visit http://www.firebirdsql.org and click the Resources item
>on the main (top) menu. Try Knowledgebase and FAQ links !
>
>Also search the knowledgebases at http://www.ibphoenix.com
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Yahoo! Groups Links
>
>
>