At 02:35 PM 1/06/2007, you wrote:

>Hi all,
>
>I'm using FB 1.5.4 embedded in a Delphi app. I am aware it uses the
>superserver architecture and that only one connection can be open to
>the DB at at time...
>
>My question is regarding the use of multiple concurrent transactions
>in multiple threads agains that single connection. Is it OK to do
>this or do you need to syncronize access to the database so only a
>single thread can be running a transaction against the connection at
>a time.
>
>I would have thought concurrent tx on concurrent threads would be OK
>until I came across this article - Overview of Firebird Client
>Library Thread Safety [
>http://kinterbasdb.sourceforge.net/dist_docs/firebird-client-library-
>thread-safety-overview.html ] which states...
>
>'Firebird client library is "thread-safe at the connection level", we
>mean that it is safe to use a particular connection in only one
>thread at a time, although the same connection can be manipulated by
>different threads in a serial fashion'
>
>Could somebody clarify this issue? I had some strange issues in
>FIBPlus (Delphi) when using multi tx+multi thread and am wondering if
>this is the cause.. hopefully not because it sucks!

You might like to review my comments in the thread preceding this one....

Embedded is a single instance of the client library connecting to a
dedicated server instance. The client library code is the same as
that which is a client to a multi-user server. The same things
apply: just as you can't have multiple threads (consisting of
transactions and statements) sharing the same connection with the
regular client/server model, so you can't do it with the embedded server.

But there is nothing to prevent your application from creating
multiple threads, each containing its own connection, transactions
and statements. I agree that the kinterbase note, while correct, is
a bit confusing. All it is saying is that it's not safe to thread
off at transaction level - you must do it at connection level, but
that it's OK to pool connections with the proper care taken to
prevent multiple threads trying to use the same connection concurrently.

In Delphi, this means creating a connection object and all of the
required statement objects within the thread and destroying them all
within the same context. However, if you want to implement some form
of connection pooling, you can use connection objects that exist
outside of the context of any executing thread, as long as you take
the necessary care to ensure that you don't have multiple threads
attempting to use the SAME connection object.

If you do this right during development with the regular Superserver
then it will work just the same with embedded. Just be aware that
you can't use the embedded model for your development in the Delphi
IDE, which needs the capability to run multiple client instances
simultaneously....embedded is a deployment model, not a development one.

./heLen