Content-Type: text/plain;
  charset="iso-8859-2"
From: Damien Dougan <damien.dougan@mobilecohesion.com>
Organization: Mobile Cohesion
To: Christoph Haller <ch@rodos.fzk.de>,
	pgsql-interfaces@postgresql.org
Subject: Re: Asynchronous Communication across two independent  components
Date: Tue, 25 Mar 2003 14:14:46 +0000
User-Agent: KMail/1.4.1
References: <3E805C93.2122D26C@rodos.fzk.de>
In-Reply-To: <3E805C93.2122D26C@rodos.fzk.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200303251414.46289.damien.dougan@mobilecohesion.com>

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?

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 cannot=
=20
issue another PQsendQuery over that connection until the PQgetQuery returns=
=20
NULL).

This is something I want to avoid - I want a completely detached asynchrono=
us=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 fo=
r=20
notifications and doesn't care how they happened - how long ago the Sender=
=20
sent them etc.

Thus I can have two threads in my system (one Sender, one Receiver) that ca=
n=20
pump messages in/out of the database as fast as they can receive them. The=
=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 abou=
t=20
it.


> Really? Before making a call to PQsendQuery you have to make sure the
> previous
> results have been completely processed by PQgetResult. So you need some
> kind of
> interprocess communication facility anyway to tell the sender when
> another
> PQsendQuery is possible. And as long as there is no ok from the
> receiver, the
> sender has to accumulate the queries.
>
> Does this sound plausible or did I get something completely wrong?

My intention is to have the Sender make a synchronous stored procedure call=
,=20
which will then make an asynchronous stored procedure call, before=20
immediately returning. Thus as far as the Sender is concerned, it is making=
=20
requests which are near instantanious. The asynchronous stored procedure wi=
ll=20
do its thing (possibly after some delay if there are locks in place), and=
=20
trigger a notification to the Receiver, which can then get the results (via=
=20
meta-data identifying the changed rows in the table) and deal with them.

Thus, unless I've missed something (please shout if I have!), I don't have =
to=20
deal with asynchronous comms via API.

The clunk is that I need meta-data and an intermediatory stored procedure=
=20
before and after table processing. Before table processing to turn the=20
synchronous Sender request into an asynchronous logic request. After table=
=20
processing to populate the meta-data so the logic in the asynchronous reque=
st=20
is decoupled from the notification parts (which are nothing to do with the=
=20
business logic).

Damien