>>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...
Of course.
>>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? 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? Not sure if the namespace ItemPool:: is the
right one.
> 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?
p.s. take your time to respond ;) I won't start looking at it until next
week probably.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
