""Wilson, Fred""

> That's correct. The factory thread, on startup, creates a pre-determined
> number of connections, and actually "connects" them to the database. When
> running, other threads "request" a connection from the factory thread,

and,

> if one is available, it's handed to the requesting thread. If none are
> available an error is thrown. The factory thread does *nothing* with the
> connections (after the initial actually call to connect to the database,

and

> that's done before any connections are handed out). The requesting thread
> returns the connection to the factory thread (pool) when it's finished,

and

> at that time, the connection is available to be handed out to another
> requesting thread.

Ensure that no worker threads keep ANY kind of connection info lying around,
e.g. datasets, transactions...., if they do anything that interacts with
these once the connection has been given back, then you could have problems.
The BDE & FIB (I would imagine IBO does the same), have subcription /
notifcation models that mean you can work out what is reliant on the
connection, if you've rolled your own, that would be advantageous, otherwise
checking can be tricky and you get that bug from code a mile away syndrome.

> This seems to be a pretty common practice, at least with other databases,
> and seems to work well, the way it's done, with IB. There seems to have

been

> expressed, in the past, some concern about the thread safeness (is this a
> word ;) ) or the gds32.dll.

I'm sure that it is threadsafe as long as your granularity is at the
connection level.

> We've seen no problems, so far, sharing connections between threads, as

long

> as the "owner" thread is the only thread doing anything with the

connection

> during the time that it owns it, and it's returned in a "usable" state,

that

> is the owner thread has no open tranactions pending on it, etc.

Cool.

JAC.