My general approach to new features is to encourage people to implement them using driver-private methods or DBIx::* modules first. We can discuss spec changes once we've got some real-world experience.
I think connection pools could be implemented as a DBI sub-class or via the Callback mechanism. In relation to Apache2, to be more useful than connect_cached the connection pool really needs to be shared between threads. Search the archives for emails mentioning DBI::Pool, DBI::ThreadPool, Apache::DBI::Pool and take_imp_data. You could start here: http://perl.markmail.org/search/?q=DBI+Pool+from%3A%22Tim+Bunce%22 But, as far as I know, few people are using threads with mod_perl2. I'd recommend that before you start writing anything you discuss it widely and make sure you've got (and can explain) a clear view of the problem you're trying to solve. As you can tell from the link above, there's been some small interest for years but nothing much has come of it. Tim. On Thu, Jun 12, 2008 at 12:04:22PM -0400, John Scoles wrote: > I have been doing a little research into connection Pooling with OCI and I > was just wondering if the concept of a "Connection Pool" would fit into the > DBI spec someplace. > > As we already have DBI::Apache and "connect_cache" would it just be > redundant to add this "connect_pool" as the present functionality can be > 'Bent' to that way? > > Say something like this > > $DBI->connect_pool($pool_name,$data_source,$username, > $password,$min_connections,$max_connections,\%attr); > > The idea being one could create two separate pools at the Apache level one > for lets say "Read_only_Users" and one for "Read_Write_Users" and use > connections out of the pool. > > Or am I just creating something that no-one else will use?? > > cheers > John Scoels
