Subject Re: [ib-support] Application freeze due parallel connection attempt
Author Helen Borrie
At 03:01 PM 15/02/2003 +0100, Martin Rohla wrote:
>I have an application, which creates multiple threads and each of them
>tries to connect to Firebird DB and do something. I work with DB
>through ODBC, but I guess the problem wont be in ODBC drivers. What
>have I found out so far:
>- If I create multiple connections in one thread, i.e. serially, it
>works OK
>- If I try to create connections in multiple threads, the program
>enters ODBC connect function, but never leaves
>- If I tried to do a synchronization on creating the connection, the
>first thread created it succesfully, but all other threads froze in
>it. Also, the first thread was stuck in first ODCB function it called
>after some other thread froze in connect function
>- If I do synchronization on the whole function (i.e. from creating
>the connection, to freeing it) it works, but that's the same as if I
>do it in one thread and that's not what I would like to
>- I tried it in Firebird 1.02 (latest release) and Firebird 1.5 beta2,
>build 2284 (also the latest so far)
>- all this problems are ONLY if I connect to server as local server.

The local server does not support multiple threads. In fact, the local
server in SuperServer has very limited capability, due to the way its
network layer was designed.

>When connection over TCP/IP or NetBeui, it works fine (but is slower)

If all the connections are local, use TCP/IP local loopback i.e. localhost, not your machine's network address. *Don't* use NetBeui, it is
far too noisy. A series of local loopback connections will operate more
slowly than remote connections, since remote clients do not add their own
(client) resource usage to that of the server.

>- it does the same with XTG ODBC driver and Firebird ODBC driver (only
>two free ODBC drivers for Firebird I could find)
> >From the last two points I think, it is not a problem in ODBC driver
>itself (it would seem strange to me, that two different ODBC drivers
>woulds share the same error).

No, the problem isn't caused by the driver.