On Fri, Aug 02, 2002 at 01:03:31PM +0800, Stas Bekman wrote: > > >>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 :) > > Actually since you suggest that the pooling module should transparently > work on threads and without them, it probably should be something like > the following: > > [ItemPool::Thread] [ItemPool::Process] > | | > [ItemPool::Any] > | | | > [DBI::Pool] [Foo::Pool] ... [Bar::Pool] > > does this seem to be right?
I don't know if it's right - but it seems reasonable. > ItemPool::Any is the interface class for any > kind of pools, similar to DBIx::AnyDBD, so it'll automatically or by > configuration will pick the right underlaying implementation > (process-based, thread-based, etc). > > Then DBI::Pool can use ItemPool::Any to implement its pooling. > > ItemPool::Any should provide hooks API for: > > item_create > item_destroy > > for the user of this module to supply. ItemPool::Any will do the > creation/destruction, since in the threads case it must be done in the > thread that stores all the data (which is a must if C structs must be > stored). > > Am I on the right track? I think this is something where we'll have to "feel our way" into it with a prototype and see how well it works out. Staying close to the other exisiting APIs (urls below) is probably wise since we know they work :) > Not sure if the namespace ItemPool:: is the right one. Seems reasonable :) > > 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] > > Thanks Tim, I'll read this material, but if we agree that a generic > non-DBD specific implementation is required first are there any special > needs for DBI, that I didn't mention above? No idea :) Tim. > p.s. take your time to respond ;) I won't start looking at it until next > week probably. [If I didn't respond now I'd forget....]
