Dean Arnold wrote:
It also doesn't require any changes to apps, other than to use
use DBIx::Threaded;
$dbh = DBIx::Threaded->connect(...);
...and maybe observe some of the other limitations (most of
which appear to be very minor corner cases). I spose if an
app gets clever about "ref $sth" looking for DBI::st, and
gets DBIx::Threaded::st instead, it might break...but thats
a general subclass issue.
Forgot to mention that DBIx::Threaded also provides various
async interfaces (start(), wait(), etc.),
tho apps don't need to use them.
Plus, when used with other Thread::Queue::Duplex'd threads,
apps can have a generalized async capability (ie, wait on any
arbitrary TQD'd request to complete).
And finally, FWIW, if Mssr. Bunce decided to accomodate
DBIx::Threaded in DBI, its as simple as the DBI::PurePerl
solution, ie, just check that threads are available, that
DBIx::Threaded is available, and that an environment variable
is set:
if ($ENV{DBI_THREADED} && $Config{useithreads}) {
eval {
require DBIx::Threaded;
}
return DBIx::Threaded->connect(@_)
unless $@;
}
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 ?
- Dean
