> On 09-Jul-2004 10:48:42, Ann W. Harrison wrote:
> As long as you don't have two threads with active requests at the same
> time, you should be ok. Two threads can have select statements running,
> but they can both fetch at the same time.

Thanks for the response. Let me make sure I'm understanding this right and
share my thought process on this a bit...

Here's how I was going to architect this stuff:

1. Write a connection pooling library that would create, say, 8
sub-processes, each would make their own connection to the Firebird database
and keep this connection persistent for the life of the application running
on the user's workstation.
2. When a process somewhere on that computer needs access to the
database it would request access to the connection pooling 'engine'. This
would identify the next available pooled slot, but if all were being used it
would force the requesting process to wait. Available/Unavailable status
would be handled by some form of semaphore technique I would develop.
3. When one becomes available it would pass the request to that process
which would perform the query, get the cursor back, fetch all values from
the cursor and return this array of data back to the requesting process.
4. It would then set, through the semaphore process, that the
connection pool 'channel' was now available for the next requestor

This would give me the ability to manage the connections to Firebird and not
to 'over connection' to the database. Keep in mind that there could be 100
users connected at any one time. If the number of pooled connections to
Firebird is set to a preference that can be managed on a workstation by
workstation basis, I can keep the number down.

Now the key factor in all of this design work is that the multiple
connection pools in the application can asynchronously connect to Firebird,
and execute queries, manage cursors and fetch data back. From what I
understand you are saying, this is not the case - it won't work. But am I
misunderstanding this?

> Connections aren't all that expensive and would save you a lot
> of synchronization.

Well if creating 500-1000 connections to a Firebird Server isn't a big deal,
then maybe I'm over engineering this for no return. But I just have a gut
feeling that if I don't manage these connections properly I'll overwhelm a
server quickly. Thoughts?

Regards,
Myles

===============================
Myles Wakeham
Director of Engineering
Tech Solutions US, Inc.
(480) 451-7440
www.techsol.org