Tim Bunce wrote:
On Sun, Apr 29, 2007 at 09:53:29AM -0700, Dean Arnold wrote:
It doesn't appear in CPAN search, and the link from
DBI's POD returns "not found". I found an old email
pointing to Stas Beckman's personal website, but
its no longer there either.
I've attached the latest copy I have from Stas, which I'm sure is the
latest as I know neither Stas nor I have done any work on it recently.
OK, thnx.
FWIW: I'm trying to better understand how the "brain surgery" works
I'll happily answer any questions not answered by the take_imp_data() docs.
with an eye toward (a) how to make it work w/ pure Perl DBDs, and
well, as a first step I've just done this:
--- lib/DBI/PurePerl.pm (revision 9465)
+++ lib/DBI/PurePerl.pm (working copy)
@@ -844,7 +844,16 @@
warn "private_data @_";
}
sub take_imp_data {
- undef;
+ my $dbh = shift;
+ # A reasonable default implementation. Typically a pure-perl driver would
+ # have their own take_imp_data method that would delete all but the
+ # essential items in the hash before einding with:
+ # return $dbh->SUPER::take_imp_data();
+ # Of course it's useless if the driver doesn't also implement support for
+ # the dbi_imp_data attribute to the connect() method.
+ require Storable;
+ delete $dbh->{$_} for (keys %is_valid_attribute);
+ return Storable::freeze($dbh);
}
sub rows {
return -1; # always returns -1 here, see DBD::_::st::rows below
All the really matters is that the driver's take_imp_data() method
produces a simple scalar value that the driver's dbi_imp_data attribute
can use to restore a working connection.
(b) what (if anything) I might do to accommodate it
in a threads::shared replacement I'm developing.
Could you give some more details?
Tim.
See http://www.presicient.com/sociable (very preliminary).
In brief, it provides:
- faster threads::shared (current benchmarks 2x faster for simple
scalar reads,
about 3x faster for writes on single core system; multicore
should be significantly faster)
- integrated thread queue for faster inter-thread (esp. duplex)
communication
- ...which provides for faster apartment threading
- interthread tie() (ie, tie() a variable in 1 or more threads,
access from an external thread activates the tie()'s in the
threads)
- transactional memory aka STM
As to the DBI::Pool interest, I want to make sure handles can
be pooled/cached in a Sociable container.
When updated to use Thread::Sociable, DBIx::Threaded should be
quicker than the current implementation, support the tied object i/f,
and retain the benefit of not requiring any DBD changes.
Alas, unless/until iCOW is implemented, the footprint of a single thread
per connection is too expensive for more than a few
connections. (however, a std. async DBI API would permit multiple connections
per apartment - but that would require DBD updates.)
Wrt take_imp_data() for pure Perl drivers: Your patch is similar to
what I thought, tho I'm unclear on the behavior of driver-specific vs. DBI
attributes ? Is your patch deleting the DBI attributes before
marshalling the remainder into a scalar (via Storable) ?
I've vague notions about avoiding the Storable step
if the connection context is stored in a Sociable (or threads::shared)
variable/object (tho threads::shared access overhead may be worse than
Storable marshalling).
Of course, there's the little matter of migrating filehandles
between threads...ideally, that could be solved by providing
Sociable (or threads::shared) handles (currently on Sociable's
TO DO list).
Dean Arnold
Presicient Corp.
