Yes, I was thinking about a threaded client that would be able to
fetch from several portals (quasi) simultaneously and repeatedly (but
with other parameters) over 1 TCP/IP connection.

The only thing that bothers me is the Sync command that would put an
end to all portals at once isn't it? The docs seem to say you need
to issue a sync after each cycle. There doesn't seem to be a
possibility to selectively keep some portals open this way.

That's what I make from reading the docs, I haven't had the chance to
actually experiment with it yet. (I'm in the process of implementing
the frontend-backend protocol v3 for my IDE. Only after that can I
start experimenting.)

Marc

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

"M. Bastin" <marcbastin (AT) mindspring (DOT) com> writes:
Not if you are inside a transaction block (ie, have issued a BEGIN
command).

A possibly more serious issue is that an error detected in any one of
the portals aborts the transaction and thus you lose all the portals.
We may eventually have a solution for that involving subtransactions.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

This is a "best practice" question.

Imagine you have 2 computers. One is a web server and the other runs
PostgreSQL. Multiple browsers from all over the net connect to the
web server, but to minimize load, the web server itself opens only 1
TCP/IP connection with PostgreSQL. (This is a general question, it
doesn't have to be a web server. It could be any kind of
"middleman".)

How would all the browsers be best served simultaneously?

The solution I think about is to use the extended query protocol,
open an infinitely lasting transaction, and have a portal per browser.

That would work to read data until an error occurs and the
transaction would roll back and then *all* browsers' sessions would
have to be reset.

(Therefore to write data I'd have to cheat and still open a second
TCP/IP connection over which each insert or update gets committed
instantly.)

Is there a better way to implement concurrent users over 1 single
TCP/IP session?

Thanks,

Marc


At 1:34 PM -0400 7/1/04, Tom Lane wrote:

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)