| Subject | Re: [firebird-support] Re: Embedded server and separate processes |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-02-20T00:30:23Z |
At 11:06 AM 20/02/2009, you wrote:
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.
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
>> >am I correct toNo 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.
>> >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.
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.
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