On Tue, Jul 26, 2005 at 01:20:44PM -0700, Dean Arnold wrote: > > > >Dean, check the discussion on take_imp_data and DBI::Pool[1] in this > >list's archives. > > > >[1] http://stason.org/tmp/DBI-Pool-0.02.tar.gz > > > >You can't really use Storable to snatch the underlaying datastructs from > >a random DBD. Tim has started working on take_imp_data and DBD::mysql is > >the first one to have a support for it. But there are issues with it and > >I was waiting for Tim to fix those in DBI before moving on with DBI::Pool. > > > >The advantage of DBI::Pool is that it'll work transparently for the > >users (like Apache::DBI does), and require no special coding. > > Doesn't it require special coding in the DBDs ? (i.e., each driver > has to implement take_imp_data() and possibly other stuff ?)
Few will need to override take_imp_data(), but even for those that do it will only require a little house-keeping and then calling SUPER::take_imp_data(). The change that drivers will need to implement is to support being passed a dbi_imp_data attribute at connect time. But even that is pretty trivial: basically if given dbi_imp_data then skip the call to the underlying DB APIs connect because the imp_data already contains a valid connection. > Will it permit the DBI-derived objects to be passed between threads > (i.e., will it automagically marshal/unmarshal the objects into > something that can be passed, e.g., on a queue) ? (General, Perl case, > not Apache-specific) It 'only' enables a connection made in one thread to be 'loaned out' to another thread. Which is perfect for DBI::Pool. (In theory it could also enable a statement handle made in one thread to be 'loaned out' to another, but I'll wait till it's working for connections before exploring that further.) > DBIx::Threaded derived objects are automagically marshalled/unmarshalled > (assuming the app uses Thread::Queue::Duplex to pass things around), > due to the apartment threading model used (apps just get thin > veneer client objects, all the real work goes on inside the apartment > thread) All that does add overhead of course. DBIx::Threaded will have higher method call cost to be traded against the greater functionality. > But take_imp_data() does make me a bit curious...I'm wondering > if DBIx::Threaded could use it to return its small underlying > context (rather than requiring every driver to be updated), and > thus let any DBD (running inside an apt. > thread, of course) play nice w/ DBI::Pool ? The take_imp_data() method necessarily leaves the donor handle 'brain dead'. I guess a put_imp_data() method could be added to provide resuscitation... Tim.
