On Wed, Jul 24, 2002 at 09:46:43AM +0200, Elizabeth Mattijsen wrote: > At 09:28 PM 7/23/02 +0100, Tim Bunce wrote: > >Each thread/interpreter needs to make it's own connection to the database. > >Handles cannot be shared between threads (either by passing or being cloned). > > This is the same type of problem that Thread::Queue::Any solves by > serializing data between threads using Storable.
Except that you can't serialize a DBI handle (or any other extension handle that uses magic to attach private data to a perl object). > I was wondering if, as an intermediate step until all DBD::xxx::driver > module authors have upgraded their modules, it would make sense to develop > a module that would at least handle the do(), rows() and > (fetch|select)(all|row|row)_(array|hash)ref family of methods by using the > same serialization process. It won't be fast, but it would work > (relatively) _now_. Kind of like a same-process proxy. I don't know if it would make sense. > > > 2.) I have been reading the discussion between Tim and > > > Gerald on cloning the DBI state. Is something similar > > > required/recommended for DBI drivers? > > > >All drivers need a DBD::<name>::CLONE method that clears the $drh handle > >so that the next connect in the cloned interpreter will trigger creating a > >new driver handle. > > > >Also any state info within the XS/C code needs to be held per-interpreter > >(ie beware static data). > > Would there be any change faking this at the Perl level externally? So > that you could create a generic module that would do the right thing on > cloning? I'm not sure what you're saying here. > > > 3.) Is there anything else I can do as a driver author > > > to verify or enhance the situation? > > > IMO it should at least be possible to load DBI at the > > > start of an application and share a pool of database > > > connections between threads. I think it's ok to restrict > > > the use of a connection to one thread at a time. > > > >I'm exploring ways of defining an api and semantics for that. > > Is there a discussion about this going on, apart from at TPC and this > mailing list? Not that I'm aware of. Nag me in a few days (once I've dug myself out of the post-conference work backlog) if I've not posted a summary of my thinking by then. Tim.
