Content-Type: text/plain;
  charset="iso-8859-2"
From: Damien Dougan <damien.dougan@mobilecohesion.com>
Organization: Mobile Cohesion
To: Darko Prenosil <darko.prenosil@finteh.hr>, pgsql-interfaces@postgresql.org
Subject: Re: Asynchronous Communication across two independent components
Date: Tue, 25 Mar 2003 12:23:46 +0000
User-Agent: KMail/1.4.1
References: <200303241535.25156.damien.dougan@mobilecohesion.com>
	<200303250915.48917.damien.dougan@mobilecohesion.com>
	<200303251313.25238.darko.prenosil@finteh.hr>
In-Reply-To: <200303251313.25238.darko.prenosil@finteh.hr>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200303251223.46076.damien.dougan@mobilecohesion.com>

On Tuesday 25 March 2003 1:13 pm, Darko Prenosil wrote:

> How about sharing connections between sender and receiver. After all
> PGConnection is only pointer that can be same for Sender and Receiver.
> How do you mean to connect Sender and Receiver ? How should postgres know
> which Sender will post results to which Receiver ?

I understand why the PQsendQuery and PQgetResult won't work across=20
connections, so that's not an issue.

> The only way to have sender and receiver on different connections is to
> write some kind of own server that will connect server and receiver to
> "Pair", but I did newer heard for such "construction" in SQL server
> philosophy.
>
>  It is also possible to store the "results" from Sender to tables, and
> Receiver can periodically check if something happened and get the results!

Yes - that's what I intend doing with the LISTEN and NOTIFY - I will have a=
=20
Trigger StoredProc that will be called when a table is updated in response =
to=20
the Sender issuing a request. The Trigger StoredProc will then insert an=20
entry in another table that will result in a notification.

I've separated out the logic of insertion into the notification table into =
a=20
Trigger StoredProc because its not really part of the logic of updating our=
=20
schema tables - effectively the notification table is meta-data to help the=
=20
Receiver determine what has been changed.

I just think this is a little clunky and was hoping for something cleaner .=
..

> That is true, but why do you wish to send another query if you send them
> all in one PQSendQuery ?

Our architecture is message based, so I can't delay the Sender waiting for=
=20
incoming messages (buffering them together) into a single PQsendQuery becau=
se=20
its all asynchronous communication.

> Unfortunately RAISE NOTICE can only function through same connection, and
> if You insist on different connection, this will not help.

Again, thanks for the heads-up on this!

Damien