2011/1/5 Вячеслав Блинников <slavmfm@gmail.com>:
> The whole thing is:
> - server connect to the database and wait for incoming connections
> - when incoming connection occurs, server request the database for some data
> about connected client - server must do it asynchronously and without
> creating any threads just for connected client (there can be more than
> thousand clients)
> - at moment of requesting data from the database there already can be some
> active requests
> - when database respond it is need to know for which client this data
> received (and what kind of request it was)
> That's all.
>
> P.S. it is possible to implement it requesting data one-by-one (adding each
> request to the queue and popping (FIFO) each request after each database'
> respond) but it is slow because it's need to wait data transferring through
> the net while database (server) itself will be idling.
I'm afraid I don't understand your problem, but may I suggest that you:
1. Wrap the connection in a semaphore. This isn't pretty, but if I've
understood you correctly, it will do the job.
or
2. Have one database connection per "server" client. Having one
process that itself has up to a thousand clients but uses only one PG
connection is a very questionable approach - the single database
connection is certain to become a bottleneck.
and
3. Use a connection pooler.
--
Regards,
Peter Geoghegan