Chris Withers wrote at 2004-8-16 13:48 +0200:
...
There probably is a reason that you allow seven threads. When the connection pool is not ready to allocate seven connections, you will get less concurrency than you (apparently) want.
I don't understand what you're trying to say here...
The current Zope code uses connection pooling: each DA instance is a pool. Its capacity is min(number_of_threads, number_of_ZODB_connections). When another pool implementation has lower capacity, concurrency is restricted.
... Yep, but rather than creating one connection for each Zope thread, it only creates as many connections as are concurrently needed, and that's almost always a MUCH lower number...
Looks as if you close connections as fast as possible? You are aware that some database systems (Oracle seems to be) have long connection times?
... With a connection pool, the worst case number of connections is the largest number of concurrent requests. Without one, it is the number of Zope threads (plus some for those leaked by _v_ variables),
There are no "_v_variable" leaks.
regardless of the load on the server.
The current pool is not so stupid. When it opens n connections than the server was hit by at least n concurrent requests. It is true, that not all of these concurrent requests need to access the database.
...
Implementing a connection pool correctly is tricky (when one request requests two connections from the same DA, it *MUST* get the same connection).
I'd be interested to hear your thoughts on the code in ZOracleDA on the branch I created...
I am not so keen to participate in code reviews. We are (apparently) happy with the current ZOracleDA code (the standard one, not that on your branch). No need yet, to look at your code. This will change, however, when your pooling enters the DA core in Zope -- and our Postgres interaction should no longer work correctly (I use Postgres, colleagues fight Oracle). -- Dieter