You simply queue things up and serialize them in your application.
I queue things in virtual memory with a check to make sure there is no
overrun of space.
If there is then things are pushed into a temporary file.

If the database connection isn't up then there needs to be a place your
incoming information can go on a temporary basis anyway. This way there
isn't an exterior failure of service and recovery is as simple as handling a
peak push of information. Of course if something is waiting for the work to
get done there is a failure but it's much simpler than a crash and burn.

This is all just a matter of keeping things designed properly and putting
what belongs where it belongs.

As for your design of one thread per logged on client, that doesn't sound
like good design to me where scaling is concerned.
What you really need is a clean running queue and a few good and healthy
threads to service the queue.

But, this subject really does digress from the IBO realm...

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: "Arno Garrels" <arno.garrels@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, January 15, 2003 4:36 AM
Subject: Re: [IBO] Multithreading (was: Access violations in ibserver.exe
and gds32.dll)


> Hi Jason & Christian,
>
> >
> > > 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.
>
> > I think I understand what you mean, but I am not really sure.
> > If you have the time, it would be great if you could elaborate.
>
> I think I did NOT understand what Jason said, I would appreciate as well
if
> Jason could light the dark.
>
> Here is my example:
> I've made a socket server that authenticates clients by a query on a FB
> table (in fact it does a little more:). Each time a client logs on, I
start
> a thread for that task. If I wouldn't do that and multiple clients logon
> simultaneously, then they would be rejected because the server won't
respond
> to all requests.
>
> Currently I cannot imagine how to manage it using just a single
connection.
>
> Regards
> Arno Garrels