Thanks for the replies; that's helpful.   It would make sense that the embedded engine would run as it's own thread, but still in the process context of the client app.   We actually want it to run in a separate process (like you would get if a full server were running on the current machine), but still be easily deployable and flexible like the embedded server is.   The advantages of having it in a separate process are that it reduces memory footprint of the client app (which is helpful when you're running into the 3/4GB limits of 32 bit applications), and robustness: if my client process crashes, it's less likely to corrupt the database, and if the database engine crashes, it's less likely to bring down my app. 

Anyway, it sounds like deploying a full server is the easiest way to do this (unless someone knows the source code well enough to say whether we might be able to easily modify the client/server code to work more like this).

-Paul



________________________________
From: Alan McDonald <alan@...>
To: firebird-support@yahoogroups.com
Sent: Thursday, February 19, 2009 4:42:14 PM
Subject: RE: [firebird-support] Re: Embedded server and separate processes

> At 11:06 AM 20/02/2009, you wrote:
>
> >> >am I correct to
> >> >assume that on Windows, the embedded firebird engine is running in
> >> >the same process as the calling app,
> >>
> >> Two processes running in shared IPC space
> >
> >Are you sure about that?
> >
> >I thought the embedded engine on windows (fbembed.dll) was linked into
> >the client application. At least, that is what process explorer tells
> >me when I look at who has the handle to the database.
>
> No doubt Dmitry can clarify...but my understanding is that the
> application process + the client component of fbembed.dll (which your
> system should see as fbclient.dll, right? unless you are using some way
> to override the name of the loaded client) comprise one process, while
> the server component - a single SS instance - runs as a separate
> process that lasts the life of the embedded attachment.
>
> I think this is right. Your application code is running in its own
> application space. Initially, it has no connection with a DB server.
> It loads the API part of fbembed.dll: now it is associated with a
> client instance. It has not yet passed any request to connect to a
> database.
>
> Then a connection request is passed through the API. If it succeeds, a
> thread of the embedded SS is now running. Potentially, other threads
> may run simultaneously, e.g., a garbage collection thread running in
> background.

threads... correct, separate process in the processes list.. no, incorrect.
the entire embededd dll is running in the application space.
this may be a matter of semantics, but "separate processes" refers to a
running prcess with it's own PID in the processes list.
Alan

>
> The application disconnects. Now, no SS thread is running, although
> the application still is, and the API is still loaded. Next, you might
> invoke the embedded Services Manager and request a backup, statistics,
> or whatever. When that starts up, it starts a fresh SS instance that
> runs a thread. The client waits for the result and that instance of SS
> shuts down....and so on.
>
> ./heLen

[Non-text portions of this message have been removed]