Re: Asynchronous Communication across two independent

>
> On Tuesday 25 March 2003 1:41 pm, Christoph Haller wrote:
>
> > Yes, share connection by a common PGconn data set, write/read via a
> > binary file
> > or whatever interprocess data exchange you prefer.
>
> But doesn't this approach limit the number of database operations to
the=20
> number of threads in our platform?
No, I don't think so.
>
> If I have a connection shared between a Sender and a Receiver, I have
two=
> =20
> threads waiting on a single database operation to complete (since I
canno=
> t=20
> issue another PQsendQuery over that connection until the PQgetQuery
retur=
> ns=20
> NULL).
But they behave as one thread, and yes, another PQsendQuery has to wait
until PQgetQuery returns NULL.
>
> This is something I want to avoid - I want a completely detached
asynchro=
> nous=20
> communication model. A Sender fires messages into the database and
doesn'=
> t=20
> care for the results - when they happen, what they are. A Receiver
waits =
> for=20
> notifications and doesn't care how they happened - how long ago the
Sende=
> r=20
> sent them etc.
>
> Thus I can have two threads in my system (one Sender, one Receiver)
that =
> can=20
> pump messages in/out of the database as fast as they can receive them.
Th=
> e=20
> database can worry about locks - its internal architecture should be
well=
> =20
> designed to cope with that - my business logic shouldn't have to worry
ab=
> out=20
> it.
This is what I thought you're going to implement on your own.
I've never heard of any pump mechanism as you describe it as a
pre-defined feature. So if you write two C programs acting as
sender/receiver daemons in the background, from a black box
point of view, they would offer exactly this functionality.
I would be interested in hearing about platforms which
offer that by default.

Regards, Christoph