> I am getting reports that DBD::mysql has trouble with > cloned handles.
No surprise. It won't work. > I apologize if my questions are stupid, > but I am too much out of the Perl business to be on > top, so I have to ask. (Still sad to write that. :-( > > 1.) What is the current state of DBI and iThreads. Usable? > Not recommended? Thread safe? Thread friendly? What > else? (Of course a detailed explanation *why* would > be welcome. :-) Usable. But there's no protection against multiple threads entering non-threadsafe client library code (.dll/.so). 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). > 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). > 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. > Btw, do Apache::DBI or DBI itself support a cleanup of > resources (database handles and statement handles) if > I "close" the connection, effectively returning the > connection to the pool? No. There isn't really a 'pool' concept. That needs to be added. Tim [at the perl conference].
