I always enjoy reading and considering your questions, and often I am entertained or even staggered by the 'solutions' you cook up. However, what problem are you trying to solve by spawning 16 - 25 versions of the same process? My suspicion is that you are trying to efficiently maximise resource usage and get the task in question done in less time, but often things like these are not infinitely scalable. Sometimes they're not scalable at all. In this case I would suspect that the process execution would be bottlenecked by MySQL, in which case you'll never get any improvement of performance and you may even see degradation thanks to the O/S and MySQL kernel having to manage all these processes hitting the database at the same time.
Not to mention that you are also then required to invent hare-brained schemes like the ORDER BY rand() in order to try to avoid deadlocks and race conditions in your database updates. As a general rule, when it comes down to (1) write code to synchronise access and updates to a database, and (2) let the database do it for you, it's very rare that the best idea is not (2) let the database do it for you. So anyway.. if you're still convinced you want 20 processes to do the same job as the one, Dmitry's suggestion of SELECT ... FOR UPDATE will 'transactionalise' the database accesses and solve your synchronisation problems. --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
