From: Damien Dougan <damien.dougan@mobilecohesion.com>
To: Darko Prenosil <darko.prenosil@finteh.hr>
To: pgsql-interfaces@postgresql.org
Subject: Re: Asynchronous Communication across two independent components
Date: Tue, 25 Mar 2003 12:23:46 +0000
Message-ID: <200303251223.46076.damien.dougan@mobilecohesion.com> (raw)
In-Reply-To: <200303251313.25238.darko.prenosil@finteh.hr>
References: <200303241535.25156.damien.dougan@mobilecohesion.com>
<200303250915.48917.damien.dougan@mobilecohesion.com>
<200303251313.25238.darko.prenosil@finteh.hr>
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
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
Trigger StoredProc that will be called when a table is updated in response to
the Sender issuing a request. The Trigger StoredProc will then insert an
entry in another table that will result in a notification.
I've separated out the logic of insertion into the notification table into a
Trigger StoredProc because its not really part of the logic of updating our
schema tables - effectively the notification table is meta-data to help the
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
incoming messages (buffering them together) into a single PQsendQuery because
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
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: damien.dougan@mobilecohesion.com, darko.prenosil@finteh.hr
Subject: Re: Asynchronous Communication across two independent components
In-Reply-To: <200303251223.46076.damien.dougan@mobilecohesion.com>
* 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