On Wed, Jul 31, 2002 at 11:45:06AM +0800, Stas Bekman wrote: > Hi Tim, > > It was great to see you at the conference!
Likewise Stas! > Did you have a chance to put some initial code for the DBI::ThreadPool > we discussed on Sunday before the conference started? No chance. Things have been fairly manic since I returned. It'll be next week before any kind of sanity is restored. Meanwhile this email is just a stream-of-consciousness brain-dump... I've CC'd dbi-dev to save having to repeat most of it later... > What do you think it is better to start with? A generic Thread::ItemPool > and build DBI::ThreadPool on top of it, or the other way around? I think a baseclass + subclass approach seems reasonable. Which has the handy benefit of letting me delegate the base class to you :) I did some digging and found this handy article http://www.webdevelopersjournal.com/columns/connection_pool.html that looks like a handy guide to the Java serverlet connection pool and connection manager APIs. Other useful-looking links: http://www.javaworld.com/javaworld/jw-10-2000/jw-1027-pool.html http://www.webdoyen.com/java/doc/com/webdoyen/database/ConnectionPool.html http://ccm.redhat.com/doc/core-platform/5.0/api/com/arsdigita/db/DatabaseConnectionPool.html http://ccm.redhat.com/doc/core-platform/5.0/api/com/arsdigita/db/ConnectionManager.html It occurs to me that the connection pool concept is equally valid in a non-threaded environment (like apache 1) and any (DBI) API we define should work transparently across threaded and non-threaded environments. We currently have Apache::DBI and DBI->connect_cached both providing a kind of connection *sharing* mechanism (with extra bells-n-whistles in the Apache::DBI case). By connection sharing I mean that two consecutive connect requests with the same params will both get the same $dbh - they'll be sharing it. A typical connection 'pool' concept is based around the 'exclusive loan' of a connection from the pool, which is later returned to the pool when no longer needed. While on loan it's not available for other pool requests. Two consecutive requests with the same params will get different connections. I'd ideally like a connection pool mechanism to be able to sit underneath the connection sharing mechanism so that, for example, multiple connect requests within the same apache request can share the same handle, but at the end of the apache request the handle is returned to the pool. [No time for more rambling] Tim.
