From: Christoph Haller <ch@rodos.fzk.de>
To: pgsql-interfaces@postgresql.org
Cc: damien.dougan@mobilecohesion.com
Subject: Re: Asynchronous Communication across two independent
Date: Tue, 25 Mar 2003 15:44:44 +0100
Message-ID: <3E806B5C.1F003BE8@rodos.fzk.de> (raw)
>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: ch@rodos.fzk.de, damien.dougan@mobilecohesion.com
Subject: Re: Asynchronous Communication across two independent
In-Reply-To: <3E806B5C.1F003BE8@rodos.fzk.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox