> 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.
And this post is somewhat entertaining reading (nonwithstanding that I will take on board your recommendation above) because it assumes that the 'processing' that the script is doing is for the Database, when in reality it's not. All the DB does is keep a track of the over all 'list' on work to be done. And yes, as many processes as I can throw at it certainly speeds things up. The limit at present is caused the the before mentioned DB issues. Michael --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
