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. 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_. > > 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? > > 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? Liz
