Milan Babuskov wrote:

> Helen Borrie wrote:
>> Windows Yes. With libfbembed.so on Linux and a direct connection to
>> 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.)
>
> This makes me wonder. I use fbembedd.so on Linux and it still spawns the
> lock manager (running under my Linux account instead of firebird or
> root). I guess it's just a side-effect?

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 up.

>>> 2. Can external programs also make a connection to the database while in
>>> use by the application? Same with Windows and Linux?
>> No.
>
> Given that lock-manager IS running, perhaps another application started
> by the same Linux user would work?
>
> I just tried it with 2 instances of FlameRobin running in parallel and
> it does work. I checked and I have only one lock manager running (under
> my 'milanb' account):
>
> milanb@asus:~$ ps aux | grep fb_lock
> milanb 1847 0.0 0.2 3344 1068 ? S 22:49 0:00
> /home/milanb/devel/fb-2.0.1-fr/bin/fb_lock_mgr
>
> However, there are 2 FlameRobin processes holding the database file open:
>
> milanb@asus:~$ lsof | grep DB
> flamerobi 1837 milanb 6u REG 3,8 6225920 478557
> /home/milanb/devel/fb-2.0.1-fr/baze/DB.FDB
> flamerobi 1845 milanb 6u REG 3,8 6225920 478557
> /home/milanb/devel/fb-2.0.1-fr/baze/DB.FDB
>
> The situation looks exactly the same when I run regular Classic via xinetd.

So this is two programs each opening the database file directly using
the libfbembed.so library? I thought that wasn't possible. Does it all
actually work properly?

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. It would be really nice to have this
working though and I wonder just what the thread safety issues are. I
imagine there is static data used in libfbembed that isn't protected by
a mutex. I wonder if I wrap all calls to functions in libfbembed.so in
my own mutex so that no two threads use the same function at once if
that would make it all work. Even better would be to know just which
calls have threading safety issues and only block multiple threads from
calling those functions. Any hints on this?

>>> 3. What files need to be included when installing Firebird embedded with
>>> Linux and Windows?
>> For Linux, it is just a normal Classic install.
>
> Here's a detailed explanation for FB1.5, FB2.0 needs ICU files as well:
>
> http://sotu.berlios.de/Firebird-Embedded-Linux-HOWTO.html

Thanks for the link and info. Funny but this howto references some info
I wrote up back in 2005 on how to get Firebird embedded running on Linux!

>> 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.
>
> Please note that actually it does not prevent anything.

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. I can see that the SuperServer design should be locking the
database file so that you can't accidentally have two servers using it
at once but again this depends on SuperServer setting the lock *and* it
checking the lock itself before trying to open the file. As Milan says
this locking is purely advisory.

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

1. Classic:

- check if the database is locked and if so, don't allow use
of it
- don't set a lock on the database

2. SuperServer:

- check if the database is locked and if so, don't allow use
of it
- set a lock on the database when in use

3. Embedded:

- check if the database is locked and if so, don't allow use
of it
- set a lock on the database when in use

Sounds like this is not how its working though so perhaps I'm missing
something...

--
Brad Pepers
bpepers@...