[Zope] Re: MySQL thread connection question

[Dieter Maurer]

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