> On 09-Jul-2004 08:46:29, Martijn Tonies wrote:
> Interesting. Thanks for the explanation as, I think, most of us
> here are Delphi programmers :-)

My guess is that it probably wouldn't be that different an issue in Delphi.
After thinking this through a bit more, it does make sense to have one
persistent connection per workstation that all processes/threads share, and
even if the data is moved synchronously through the connection, the fact is
that a user pretty much does one thing at one time. They might be in an
illusion that they can have a ton of Windows opening, but in a normal day,
the frontmost window is the only one that is actively working with the
database.

That said, it doesn't make much sense to bog down the Firebird server with
more connections than it needs to manage on the chance that one of the other
processes 'might' be doing something with the database in the background.
This would limit the max number of user connections available to the
database, without any decent return on the investment.

So therefore I'm now rethinking my architectural approach. I guess
sometimes when you have the power to do multi-threading as is offered with
Firebird, it doesn't mean that it makes sense to use it. I have experience
with Sybase in regards to this, from a few years back, and their client
library flatly refused to be anything but synchronous. But in retrospect,
maybe this just made us approach the design in a more controlled fashion,
and in retrospect it didn't affect the user experience that much.

Regards,
Myles

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