Oh yes there is a very easy solution.
If you write a mass update process like in your example you skip the
records with a lock and write them to an error log file.
That way you never end up in a "deadly embrace".
After you finished the mass update you can then check for skipped
records and update them later.
Or with the LOCKED clause you can let both parties know who is locking
whom out and resolve the deadlock amicably by getting the sales person
to exit the sales rep screen and file the customer record in your
example. Ideally you should use a subroutine that tells you who is
locking you out instead of READUs anyway.
Mecki
On 25/10/2011 18:27, 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
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
