Threads and MySQL

chrispete has asked for the wisdom of the Perl Monks concerning the following question:

I have a situation where I need to grab data from a MySQL database, launch threads based on that data, and then access the database from the threads to pull more data specific to what those threads are working on. I keep getting a "DBD:MySQL doesn't needs CLONE(), can't clone handle." I understand what is happening, the handle that I set up in the program before the threads are launched is giving me problems. My assumption was that I should be able to completely destroy the handle before going threaded and that should make it work (a previous version of this program worked when there was no DB access before the threads were launched, but I need some data before launch now.) Here's my problem: I've used every method I can find from MySQL, DBI, and Perl itself to try and kill this handle before going threaded and nothing will work. Any ideas?

Comment on Threads and MySQL

Replies are listed 'Best First'.
Re: Threads and MySQL by BrowserUk (Patriarch) on Jan 31, 2005 at 17:12 UTC
The DBI guys say that DBI and threads do not mix. You had best trust their word. If your child tasks do not need to communicate back to the parent, a fork and exec approach is probably easier and safer. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]
Re: Threads and MySQL by osunderdog (Deacon) on Jan 31, 2005 at 17:19 UTC
You might look at POE there is an example in their cookbook that sounds close to what you are trying to do: DBI_Helper_Processes *"Look, Shiny Things!"* is not a better business strategy than compatibility and reuse.	[reply]
Re^2: Threads and MySQL by chrispete (Initiate) on Jan 31, 2005 at 19:01 UTC
Thanks guys, I've been looking over what I need the program to do and can't find any reason to continue using threads (I did previously need to share data with the parent and directly between the threads) but with the new version of the program I really don't need any centralized control anymore and the processes can easily share what little data they will be exchanging (only one R/W per hour) via a hash tied to a file (this is even better as it provides a permanent storage of the hash should the system croak for some reason - it'll be able to pick up near where it left off.) Thanks for the sanity check!	[reply]
Re^3: Threads and MySQL by BrowserUk (Patriarch) on Jan 31, 2005 at 20:01 UTC
If your tasks are using MySQL, why use a shared file (with all the inherent problems of locking etc.) to share data between them? FWIW: The problem with using DBI threads is a design flaw in DBI, not a problem with your code. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]
Re^4: Threads and MySQL by chrispete (Initiate) on Feb 03, 2005 at 21:31 UTC
Re^3: Threads and MySQL by osunderdog (Deacon) on Jan 31, 2005 at 19:57 UTC
Well, KISS is usually the best solution there is! *"Look, Shiny Things!"* is not a better business strategy than compatibility and reuse.	[reply]