It's not a flaw at all. In fact to do it the way you seem to imply would be
a flaw in my opinion. Here's why.

What this boils down to is where the multi-ness is ironed out. It makes a
whole, whole bunch more sense to have this entirely off loaded to the
server's internal engine processing. To expect the server software to do it
any closer to the client than it does is to subvert having the multi-ness
handled in a way that allows all clients to be handled in a truly parallel
manner. (as true as it can get anyway)

If this doesn't click for you I'll try and expand on it. There is a concept
here I'm trying to illuminate.

In short, it is worth working with how it is. There's a good reason it is
this way.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --

----- Original Message -----
From: "Christian Gütter" <cguetter@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, January 14, 2003 3:42 AM
Subject: Re: [IBO] Access violations in ibserver.exe and gds32.dll


> Hi Jason,
>
> > You don't have to start a new connection for each thread. You
> > just have to
> > make sure that only one thread is working with a connection at a time.
>
> of course you can make sure that only one thread is working with
> a connection at a time by adapting your application logic to this
> flaw or by using mutexes.
>
> But I don't think this is what multithreading is about, do you agree?
> If you use several threads for _database operations_, you have to use
> several connections, because otherwise, all of your threads would be
> waiting (a long time) for the one accessing the connection object.
> So there would be no advantage of using threads in this way.
>
>
> With regards,
> Christian