--- Brad Pepers wrote:

> From my testing back in 2005, I found that this was a problem. It
> starts an instance of the lock manager and now if you happen to also
> have a regular install of Firebird on the computer, along with the
> embedded one, the lock manager for the regular Firebird can't start

This can be worked around. If you first start the regular lock manager
(by attaching to some database) it keeps running. Later, you can run
user lock manager and everything will work fine. I have Firebird 1.5
(classic) and 2.0 (embedded) setup this way and running.

> So this is two programs each opening the database file directly
> using the libfbembed.so library?

Yes.

> I thought that wasn't possible. Does it all
> actually work properly?

Apparently it does. Please note that I didn't do extensive testing
with some concurent access.

> If this works, it seems strange that I can't use multiple threads
> in a single application and have each thread use libfbembed.so
> though there may be thread safety issues there.

Exactly. From what I know, if you make sure that each of your threads
has a separate connection, you should be fine. (disclaimer: I never
tried it myself).

> It doesn't prevent it but Firebird should be checking it.
> If they are
> setting a lock on the file to say its in use and no other Firebird
> servers should be accessing it, then it should also be checking that
> lock. In the Classic design though, I thought there were multiple
> server processes, one for each client connection, and they all had
> their own open file handle to the database so locking like this
> can't be used here.

That's correct.

> In thinking of the different architectures of Firebird, I would have
> thought the locking should be like this:

[...]

Perhaps you should re-post that to firebird-devel or Firebird-achitect?

M.