While Will's articledoes give a good, clear example of a deadly embrace,
and remediating faulty code is not trivial, the solution is conceptually
trivial and it is exactly the LOCKED clause that saves us.
If you write new code, deadlocks are easy to prevent.
Testing is non-trivial. It generally requires load or stress testing
where mutiple processes vie for the same locks.
In a nutshell: you shouldn't begin writing ANY part of a logical
transaction until you own ALL necessary locks. LOCKED clauses help you
trap cases where you can't get one of those needed locks, allowing you
to release all other related locks, (freeing up everything so the
competing process can finish its work), then you try again. No
deadlocks. QED.
My problem posed at the start of this thread represents a conceptually
trivial project but it will include retrofitting this anti-deadlock
logic. Non-trivial hours. Opportunity costs. More consistent data!
All MV platforms support this same solution.
If someone else wants to explain it in further detail for the newbies,
please, be my guest.
cds
On 10/25/2011 12:27 PM, Wjhonson wrote:
This is deadly embrace
http://knol.google.com/k/will-johnson/deadly-embrace-on-pick-systems/4hmquk6fx4gu/816#view
The Locked clause does not save us from it. There is no known trivial solution
to the problem, which troubles all multi-table, multi-user database
environments.
Perhaps we should start a new thread to discuss various approaches to the issue.
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
