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

Reply via email to