Your second solution only works if one of the processes is controlled by a human. I've encountered deadly embraces between two phantom routines.
Your first solution works, if we have the luxury of skipping locked records. Some update routines, don't have that luxury as most accountants will let you know quite clearly with loud noises and waving of arms. -----Original Message----- From: Mecki Foerthmann <[email protected]> To: u2-users <[email protected]> Sent: Tue, Oct 25, 2011 10:58 am Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o explicit readu. Oh yes there is a very easy solution. f you write a mass update process like in your example you skip the ecords with a lock and write them to an error log file. hat way you never end up in a "deadly embrace". fter you finished the mass update you can then check for skipped ecords and update them later. Or with the LOCKED clause you can let both parties know who is locking hom out and resolve the deadlock amicably by getting the sales person o exit the sales rep screen and file the customer record in your xample. Ideally you should use a subroutine that tells you who is ocking 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 olution to the problem, which troubles all multi-table, multi-user database nvironments. Perhaps we should start a new thread to discuss various approaches to the ssue. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users ______________________________________________ 2-Users mailing list [email protected] ttp://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
