Skip site navigation (1) Skip section navigation (2)

Re: Asynchronous Communication across two independent components

From: Damien Dougan <damien(dot)dougan(at)mobilecohesion(dot)com>
To: Darko Prenosil <darko(dot)prenosil(at)finteh(dot)hr>,pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Asynchronous Communication across two independent components
Date: 2003-03-25 12:23:46
Message-ID: 200303251223.46076.damien.dougan@mobilecohesion.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
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


In response to

pgsql-interfaces by date

Next:From: Darko PrenosilDate: 2003-03-25 13:13:25
Subject: Re: Asynchronous Communication across two independent components
Previous:From: Damien DouganDate: 2003-03-25 09:15:48
Subject: Re: Asynchronous Communication across two independent components

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group