Tim Bunce wrote:
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.
Could either you or Stas provide the executive summary (aka
"Passing Resources Between Perl Threads for Dummies") of how this works ?
The tarball Stas pointed me at doesn't have any real POD (just a template
README), and trying to glean the info from the mail archives is (at best)
challenging. I'm having a serious bout of cognitive dissonance trying
to reconcile what I know about
- Perl's thread model (esp. wrt sharing data)
- DBI
- writing DBD's
with what you're telling me wrt DBI::Pool. Does DBI::Pool require
that the thread being passed the connection already have the DBI
connection context as a result of being spawned out of the
thread in which the connection was created ? Will it work for
pure-Perl DBDs (seems like there'd be lots of driver-specific
context copying required...) ?
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.
Agreed. Hopefully, I'll have some empirical numbers by the weekend.
However, the flexibility of DBIx::Threaded may actually provide
some performance improvement at the "macro" level (for certain types
of apps, anyway), at the expense of performance at the micro
(ie, individual statement) level.
- Dean
