Rene Veerman wrote:
On Wed, Feb 3, 2010 at 12:35 AM, Ashley Sheridan
<ash@xxxxxxxxxxxxxxxxxxxx>wrote:
It's the reason transactions exist, to prevent things happening like this.
When you have two actions where one is dependent on the other, unless you
have a way to tie them together so that they can't be broken, you run the
risk of collisions.
Yea, and i wish they'd standarized features like that across sql servers.
But they haven't, so i avoid them like the plague.
This is why you're creating your own layer... to smooth the wrinkles
between the systems via your abstracted layer. That isn't usually a good
reason for you to do it improperly.
Whatever dependencies and threading problems might arise, there's always the
principle that says:
If it doesn't work whlie it should work and threading-timing problems are
the only possible cause, then
by delay by a random timeperiod and retry the query.
Yikes, please cite your reference for that horrible advice.
In really advanced cases, one can work with last-modified timestamps and/or
build up a simple sort of work-queue (also in a table),
whereby threads inform each other of the status of their computations.
Wow... this gets ever more complex to do something simple.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
