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: Christoph Haller <ch(at)rodos(dot)fzk(dot)de>,pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Asynchronous Communication across two independent components
Date: 2003-03-25 14:14:46
Message-ID: 200303251414.46289.damien.dougan@mobilecohesion.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Tuesday 25 March 2003 1:41 pm, Christoph Haller wrote:

> Yes, share connection by a common PGconn data set, write/read via a
> binary file
> or whatever interprocess data exchange you prefer.

But doesn't this approach limit the number of database operations to the 
number of threads in our platform?

If I have a connection shared between a Sender and a Receiver, I have two 
threads waiting on a single database operation to complete (since I cannot 
issue another PQsendQuery over that connection until the PQgetQuery returns 
NULL).

This is something I want to avoid - I want a completely detached asynchronous 
communication model. A Sender fires messages into the database and doesn't 
care for the results - when they happen, what they are. A Receiver waits for 
notifications and doesn't care how they happened - how long ago the Sender 
sent them etc.

Thus I can have two threads in my system (one Sender, one Receiver) that can 
pump messages in/out of the database as fast as they can receive them. The 
database can worry about locks - its internal architecture should be well 
designed to cope with that - my business logic shouldn't have to worry about 
it.


> Really? Before making a call to PQsendQuery you have to make sure the
> previous
> results have been completely processed by PQgetResult. So you need some
> kind of
> interprocess communication facility anyway to tell the sender when
> another
> PQsendQuery is possible. And as long as there is no ok from the
> receiver, the
> sender has to accumulate the queries.
>
> Does this sound plausible or did I get something completely wrong?

My intention is to have the Sender make a synchronous stored procedure call, 
which will then make an asynchronous stored procedure call, before 
immediately returning. Thus as far as the Sender is concerned, it is making 
requests which are near instantanious. The asynchronous stored procedure will 
do its thing (possibly after some delay if there are locks in place), and 
trigger a notification to the Receiver, which can then get the results (via 
meta-data identifying the changed rows in the table) and deal with them.

Thus, unless I've missed something (please shout if I have!), I don't have to 
deal with asynchronous comms via API.

The clunk is that I need meta-data and an intermediatory stored procedure 
before and after table processing. Before table processing to turn the 
synchronous Sender request into an asynchronous logic request. After table 
processing to populate the meta-data so the logic in the asynchronous request 
is decoupled from the notification parts (which are nothing to do with the 
business logic).

Damien


In response to

pgsql-interfaces by date

Next:From: Christoph HallerDate: 2003-03-25 14:44:44
Subject: Re: Asynchronous Communication across two independent
Previous:From: Christoph HallerDate: 2003-03-25 14:00:50
Subject: Re: Interaction between Cursor and Transaction storage?

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