Subject | Re: [firebird-support] Re: Best approach using Firebird as Java embedded database |
---|---|
Author | Helen Borrie |
Post date | 2005-04-25T00:46:13Z |
At 12:36 PM 24/04/2005 -0500, David Johnson wrote:
The original question was:
"I'm exploring Firebird as Java embedded database to J2EE based
solution. What are the best approaches using Firebird as Java embedded
database? Do we need to always run the engine as Linux/Unix-daemon /
Windows-services?"
"Embedded" gets thrown around all over the place, meaning different things
to different people. Even within Firebird, it means different things,
depending on whether you are developing on Windows or Linux. It seems to
mean something different to Java developers -- OO databases and such.
First, Firebird doesn't "embed databases" at all. It is not an OO database
management system. It is not even an "object-relational" system.
If you use the "embedded" version of Fb 1.5 for Windows, the client and
server modules of the engine are rolled into a single dll. Your
locally-based application loads this dll as though it were loading the
client module for a 2-tier connection. Then it also loads the "server"
part of the engine as an application, in the application space of the
Windows user that invokes it, for the exclusive use of that user.
The engine version that is loaded by a Windows embedded client is
Superserver, which takes an exclusive lock on the database[s] it
opens. That means that no other server running on the machine (embedded or
full) can access those databases whilst an embedded server is connected to
them. Applications use exactly the same interface to work with Windows
embedded as they would use to work with a full server, be it Superserver or
Classic.
However, the Classic model on Windows does not support this "embedded
server" model at all.
"Embedded" on Linux/Unix means using an instance of the *Classic* server
and using the libfbembed.so client to connect your application code
directly to the database file. You write application code that uses a
special version of SQL (Embedded SQL, or ESQL, a.k.a "static SQL") and you
precompile it with gpre. Gpre converts all of the ESQL blocks into
macrotised native code (C, if you are using C, Cobol if you are using
Cobol, etc.) When you compile your application code, you have what's
referred to as "an embedded application". Some of the Firebird server tools
(gbak, gsec) are embedded applications.
When you use the 2-tier model of Classic, you use the libfbclient.so
client. The xinetd daemon (or inetd on older *ixes) has a "firebird"
script that tells it to listen for connection requests on a particular
service port (3050 by default). [x]inetd starts a single process of the
server module (fb_inet_server) for each client connection.
On Linux, the Superserver model does not support the Windows-style
"embedded server" at all. A single fbserver daemon is started when the
program fbserver is invoked by the fbmgr script. For each client
attachment, fbserver creates an fbserver thread.
The applications you write for use with libfbclient.so (other than with
Java) use the published API and a data access interface layer that
interprets the headers for the application language being used. Thus,
there are layers available for PHP, Python, Object Pascal, .NET, C/C++ and
so on. Client apps running in Windows can connect to databases hosted on
Linux, Unix, MacOSX, etc. servers.
I said "other than Java", because the Jaybird driver is a *native*
driver. That gets us back to the beginning, where I suggested that you ask
your questions about "embedded databases" on the firebird-java list...
The Jaybird driver doesn't use the Firebird client libraries (fbclient.dll
on Windows, libfclient.so or libfbembed.so on *ix). It re-implements the
API and the wire protocol completely, in accordance with the JDBC
standards. I believe Roman did something with both the Windows "embedded
server" model and also with the direct-connect ("embedded application")
model in Jaybird, to make some flavour of "embedded database access"
possible transparently on either platform.
The firebird-java list is where Roman hangs out - almost 24/7 it seems :-)
- and that is where you will get the answers about the connectivity model
options for Jaybird. You could also visit the Firebird website and go to
the Development/JDBC section, where you will find links to the Jaybird
documentation.
./heLen
>Firebird will run as an application - I've just never run it that way.Hey, you'll regret saying that :-)
>
>Helen's the guru on what it can and can't do in that manner.
The original question was:
"I'm exploring Firebird as Java embedded database to J2EE based
solution. What are the best approaches using Firebird as Java embedded
database? Do we need to always run the engine as Linux/Unix-daemon /
Windows-services?"
"Embedded" gets thrown around all over the place, meaning different things
to different people. Even within Firebird, it means different things,
depending on whether you are developing on Windows or Linux. It seems to
mean something different to Java developers -- OO databases and such.
First, Firebird doesn't "embed databases" at all. It is not an OO database
management system. It is not even an "object-relational" system.
If you use the "embedded" version of Fb 1.5 for Windows, the client and
server modules of the engine are rolled into a single dll. Your
locally-based application loads this dll as though it were loading the
client module for a 2-tier connection. Then it also loads the "server"
part of the engine as an application, in the application space of the
Windows user that invokes it, for the exclusive use of that user.
The engine version that is loaded by a Windows embedded client is
Superserver, which takes an exclusive lock on the database[s] it
opens. That means that no other server running on the machine (embedded or
full) can access those databases whilst an embedded server is connected to
them. Applications use exactly the same interface to work with Windows
embedded as they would use to work with a full server, be it Superserver or
Classic.
However, the Classic model on Windows does not support this "embedded
server" model at all.
"Embedded" on Linux/Unix means using an instance of the *Classic* server
and using the libfbembed.so client to connect your application code
directly to the database file. You write application code that uses a
special version of SQL (Embedded SQL, or ESQL, a.k.a "static SQL") and you
precompile it with gpre. Gpre converts all of the ESQL blocks into
macrotised native code (C, if you are using C, Cobol if you are using
Cobol, etc.) When you compile your application code, you have what's
referred to as "an embedded application". Some of the Firebird server tools
(gbak, gsec) are embedded applications.
When you use the 2-tier model of Classic, you use the libfbclient.so
client. The xinetd daemon (or inetd on older *ixes) has a "firebird"
script that tells it to listen for connection requests on a particular
service port (3050 by default). [x]inetd starts a single process of the
server module (fb_inet_server) for each client connection.
On Linux, the Superserver model does not support the Windows-style
"embedded server" at all. A single fbserver daemon is started when the
program fbserver is invoked by the fbmgr script. For each client
attachment, fbserver creates an fbserver thread.
The applications you write for use with libfbclient.so (other than with
Java) use the published API and a data access interface layer that
interprets the headers for the application language being used. Thus,
there are layers available for PHP, Python, Object Pascal, .NET, C/C++ and
so on. Client apps running in Windows can connect to databases hosted on
Linux, Unix, MacOSX, etc. servers.
I said "other than Java", because the Jaybird driver is a *native*
driver. That gets us back to the beginning, where I suggested that you ask
your questions about "embedded databases" on the firebird-java list...
The Jaybird driver doesn't use the Firebird client libraries (fbclient.dll
on Windows, libfclient.so or libfbembed.so on *ix). It re-implements the
API and the wire protocol completely, in accordance with the JDBC
standards. I believe Roman did something with both the Windows "embedded
server" model and also with the direct-connect ("embedded application")
model in Jaybird, to make some flavour of "embedded database access"
possible transparently on either platform.
The firebird-java list is where Roman hangs out - almost 24/7 it seems :-)
- and that is where you will get the answers about the connectivity model
options for Jaybird. You could also visit the Firebird website and go to
the Development/JDBC section, where you will find links to the Jaybird
documentation.
./heLen