At 08:59 PM 23/11/2004 +0300, you wrote:

>Did anyone try to work with local Firebird from multithreading
>application ?
>I found that lastest FB still has bug #450928 (Client library not
>thread safe).
>If you start transactions from different threads the application
>hangs (the sever continue working). And it hangs even if each thread
>load its copy of fbclient DLL and initialize own API session etc.!
>The only way to work with FB from different threads is some client DLLs
>(copies of
>fbclient.dll with DIFFERENT names). :( :( :(
>Does anyone have any comments ?

Yup. :-)

First, while we do ask people not to use the bug tracker to report their
application bugs, there's not much we can do to stop them. If you follow
this particular bug report through, you'll see that it was deleted as
invalid. OTOH, there is at least one feature request in the tracker for
the connection model to be changed so that it is possible to isolate the
existence of a transaction from the existence of a connection. It might
happen some day.

So "bug #450928" is no bug and "now" is now. The reported behaviour is "as
designed" - the API does not support sharing connection resources across
threads. If you disregard this fact and decide to try to start a
transaction accessing a connection that your thread doesn't own, there's a
very good chance that the whole application will bomb when your thread
tries to cuckold memory that another thread is already using.

The main process created for the attachment is itself a thread, that owns
the connection resources it acquired for itself. If this thread creates
transactions and statement requests for itself, in the context of this
connection.

If the application creates other threads, then each thread must create its
own connection resources, transactions and statement objects.

That's what is meant when the API is described as "not thread-safe". It
means that your application must take care to ensure that each thread using
the API takes care of its own resource allocation, because the API itself
isn't aware of threads created by your application. It operates in the
contexts database connections and the transactions and statements that
pertain to each active database handle.

So, each thread that has to perform any sort of access to databases must do
so in its own isolated connection environment. That said, it is possible
for the main thread to create a pool of connections and manage them in such
a way that each connection can only be in use by one thread at a
time. Quite a few of the database access interfaces surface this style of
safe pooling.

==================================

On Windows, there's another dimension to thread-safety (or lack
thereof). If you are using the IPServer protocol ("Windows local connect",
file-path alone, with no server) then there can be no multiple threads
making concurrent connections to the same database. While the IPServer
protocol is OK for a single admin user to connect and run a utility such as
gbak or gfix via IPServer, it is not intended for production use...for
example, if your application is a web server that needs to make multiple
threaded connections, via connection pooling or by instantiating
connections ad hoc, then you must use the local loopback server as the host.

./hb