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

Asynchronous Communication across two independent components

From: Damien Dougan <damien(dot)dougan(at)mobilecohesion(dot)com>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Asynchronous Communication across two independent components
Date: 2003-03-24 15:35:25
Message-ID: 200303241535.25156.damien.dougan@mobilecohesion.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
Hi All,

I have a problem with how the interface to Postgres works (specifically the 
libpq) and was wondering if there is a known solution to the type of 
communication I wish to perform.


Basically, I have two components - one which is responsible for submitting 
calls to stored procedures (the Sender), and one which is responsible for 
handling the results (the Receiver).

(I've done it this way for a number of reasons - based on our platform 
architecture, the need to avoid tying up threads in our platform, and the 
need to store binary data in-memory whilst the stored procedure is being 
executed - this data will not be held on the database during the life of the 
database operation).


Thus my communication problems boil down to having two separate processes - I 
want the Receiver to be able to deal with the results of stored procedures 
that the Sender has executed.


I looked at the Client Interface functions, and they (PQsendQuery and 
PQgetResult) seem to require both the Sender and Receiver to be available on 
the same connection (which I don't want to have to do - since I'd be tying up 
threads in our platform waiting for PGgetResult to return NULL before I could 
subtmit another PQsendQuery).

So I'm pretty sure this is not what I'm after.


I also looked at the LISTEN/NOTIFY, which seemed promising. However, there 
does not appear to be any mechanism to identify the event that caused the 
notification. I was hoping to be able to have the Receiver handle the 
notification by going to the appropriate relation and picking up the data 
which was now ready for it - but there's no way to know which entry it is!


Is there a known Postgres solution to the problem of asynchronous 
communication with separate sender/receiver?

Is there an alternative to this approach (bearing in mind I want to avoid 
tying up threads in our platform whilst the database is doing its thing - 
especially when there may be delays due to locks from other requests). The 
key goal in the design of the solution is request throughput with a limited 
number of threads - I don't mind the database locking until some requests are 
continued, but I can't have the thread pool available to my own service being 
consumed with idle listeners!


Many thanks for any advice and pointers,

Damien


Responses

pgsql-interfaces by date

Next:From: Darko PrenosilDate: 2003-03-24 21:27:01
Subject: Re: Asynchronous Communication across two independent components
Previous:From: Tom LaneDate: 2003-03-24 14:47:39
Subject: Re: invalid large obj descriptor(0)

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