[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 |
Problem:
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
distributed.
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
performance.
Any thoughts welcome. I am just about to finalize asynchronous communication
with the backend, and need to know which way to go.
Horst
- [Gnumed-devel] pooling connections,
Horst Herb <=