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