From: Damien Dougan <damien.dougan@mobilecohesion.com>
To: pgsql-interfaces@postgresql.org
Subject: Asynchronous Communication across two independent components
Date: Mon, 24 Mar 2003 15:35:25 +0000
Message-ID: <200303241535.25156.damien.dougan@mobilecohesion.com> (raw)
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
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
Subject: Re: Asynchronous Communication across two independent components
In-Reply-To: <200303241535.25156.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