laziness, impatience, and hubris | |
PerlMonks |
Re^3: Database queue logicby monarch (Priest) |
on Jun 14, 2005 at 12:41 UTC ( [id://466510]=note: print w/replies, xml ) | Need Help?? |
You're right, you may be penalised with having to wait. But there are advantages in this. Firstly, is or is not a requirement that two SELECTs are prevented from occuring at the same time? Thus can you or can you not afford to risk having two processes perform that SELECT at the same time? You have a choice. Risk it. Or use a lock of some sort to protect against the situation whereby both processes have nothing else to do but perform a SELECT. Think about it. Reading a record from a database (SELECT) is likely to take a fraction of the time that writing a record to the database will take (DELETE). Hence, the odds of both your processes attempting to SELECT at the same time are low. So this approach will give you SAFETY while using multiple processes. You could scale to 3, 4, or 10 processes using this technique. Other techniques all impose overhead as well (and odd/even approaches perform worse if the processing time between processes varies at all). Update: changed grammar a little. Update 2: as pointed out by the reply to this post by Foxcub I was wrong to ignore the fact that the DELETE also needs to occur within the atomic action that contains the SELECT. Apologies. Update 3: added readmore tags.
In Section
Seekers of Perl Wisdom
|
|