Rene Veerman wrote:
On Wed, Feb 3, 2010 at 12:35 AM, Ashley Sheridan
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.
Application and Templating Framework for PHP
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php