X-Original-To: pgsql-interfaces@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 4F928475A71 for ; Tue, 25 Mar 2003 09:44:43 -0500 (EST) Received: from fzkmail2.fzk.de (fzkmail2.fzk.de [141.52.27.52]) by postgresql.org (Postfix) with SMTP id 0B5D8474E44 for ; Tue, 25 Mar 2003 09:44:42 -0500 (EST) Received: FROM resy5.fzk.de BY fzkmail2.fzk.de ; Tue Mar 25 15:44:45 2003 +0100 Received: œby rodos.fzk.de with ESMTP (8.8.6 (PHNE_17135)/8.7.1) id PAA18889; Tue, 25 Mar 2003 15:44:44 +0100 (MET) Message-ID: <3E806B5C.1F003BE8@rodos.fzk.de> Date: Tue, 25 Mar 2003 15:44:44 +0100 From: Christoph Haller X-Mailer: Mozilla 4.77 [en] (X11; U; HP-UX B.10.20 9000/780) X-Accept-Language: en MIME-Version: 1.0 To: pgsql-interfaces@postgresql.org Cc: damien.dougan@mobilecohesion.com Subject: Re: Asynchronous Communication across two independent Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200303/148 X-Sequence-Number: 3897 > > 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=20 > number of threads in our platform? No, I don't think so. > > If I have a connection shared between a Sender and a Receiver, I have two= > =20 > threads waiting on a single database operation to complete (since I canno= > t=20 > issue another PQsendQuery over that connection until the PQgetQuery retur= > ns=20 > NULL). But they behave as one thread, and yes, another PQsendQuery has to wait until PQgetQuery returns NULL. > > This is something I want to avoid - I want a completely detached asynchro= > nous=20 > communication model. A Sender fires messages into the database and doesn'= > t=20 > care for the results - when they happen, what they are. A Receiver waits = > for=20 > notifications and doesn't care how they happened - how long ago the Sende= > r=20 > sent them etc. > > Thus I can have two threads in my system (one Sender, one Receiver) that = > can=20 > pump messages in/out of the database as fast as they can receive them. Th= > e=20 > database can worry about locks - its internal architecture should be well= > =20 > designed to cope with that - my business logic shouldn't have to worry ab= > out=20 > it. This is what I thought you're going to implement on your own. I've never heard of any pump mechanism as you describe it as a pre-defined feature. So if you write two C programs acting as sender/receiver daemons in the background, from a black box point of view, they would offer exactly this functionality. I would be interested in hearing about platforms which offer that by default. Regards, Christoph