On Mon, Apr 30, 2007 at 09:06:24AM -0700, Dean Arnold wrote:
> Tim Bunce wrote:
> >
> >>(b) what (if anything) I might do to accommodate it
> >>in a threads::shared replacement I'm developing.
> >
> >Could you give some more details?
> 
> See http://www.presicient.com/sociable (very preliminary).
> 
> In brief, it provides:

Interesting. Thanks.

> As to the DBI::Pool interest, I want to make sure handles can
> be pooled/cached in a Sociable container.

Well, they're just plain scalars so the answer has to be yes :)

> 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) ?

Yes. It's just throwing away everything it knows isn't relevant.
There's no magic here. I've appended the current version (that passes
the test suite). It's just trying to do _something_ that's reasonably sane.
Any pure-perl driver that adds take_imp_data / dbi_imp_data support
will probably delete everything except whatever is essential to it.

> 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).

That's an optimization. First you need to get driver authors
interesting in implementing anything at all!

> 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).

Or use file descriptors.

Tim.

Reply via email to