[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] pooling connections

From: Horst Herb
Subject: [Gnumed-devel] pooling connections
Date: Mon, 2 Sep 2002 03:56:56 +1000
User-agent: KMail/1.4.6

database "commits" via client libraries are done *per connection* and not per 
cursor, unless server side cursors are used explicitly in the queries.

Shall we rely on the developers to diligently use server side cursors for 
write access, or shall we return a separate database connection for each 
service request (a la psycopg)?
I calculated for my current implementation that I would need about 20 
connections par client to do it that way; even more, if the services are 

Or, shall we request separate write and read-only connections (my favourite), 
where the read connections share one single physical connection, and the 
write access gets a connection all for itself.
Advantage: the vast majority of access attempts are read-only queries. Write 
queries are few and far between. We would reduce the number of physical 
connections needed, which would reduce ressource consumption and thus improve 

Any thoughts welcome. I am just about to finalize asynchronous communication 
with the backend, and need to know which way to go.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]