Re: Asynchronous Communication across two independent
От | Christoph Haller |
---|---|
Тема | Re: Asynchronous Communication across two independent |
Дата | |
Msg-id | 3E805C93.2122D26C@rodos.fzk.de обсуждение исходный текст |
Ответы |
Re: Asynchronous Communication across two independent components
|
Список | pgsql-interfaces |
Just out of curiosity. It may look like a bit of a hack, but as long as it is clearly documented, it seems doable: > > > How about sharing connections between sender and receiver. After all > > PGConnection is only pointer that can be same for Sender and Receiver. Yes, share connection by a common PGconn data set, write/read via a binary file or whatever interprocess data exchange you prefer. > > How do you mean to connect Sender and Receiver ? How should postgres know > > which Sender will post results to which Receiver ? That's not the point as I understand it. There is one sender using PQsendQuery, and one receiver using PQgetResult. So postgres does not even need to know there are two processes working as sender resp. receiver. > > Our architecture is message based, so I can't delay the Sender waiting for > incoming messages (buffering them together) into a single PQsendQuery because > its all asynchronous communication. > 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? Regards, Christoph
В списке pgsql-interfaces по дате отправления: