Will - you couldn't be more wrong in your last paragraph. FWIW Knowing Asvin and the systems he works on I can tell you they are anything but simple - highly complex rules handling many hundreds of concurrent processes and millions of transactions per day... in fact right at the other end of the scale.
Brian Sent from my ASUS Eee Pad Wjhonson <wjhon...@aol.com> wrote: > >It's not possible to know every lock you may wish to set in advance David, >that's the problem. >Some locks can be set, but unknown, until the user has done something. >Like in my example where the user changing a field in one record, causes >another update to be triggered in some other record. >You cannot know that in advance, that is, you cannot determine what the user >may do next, so you cannot set the lock in advance, but only at-the-time they >act, which will be after the main lock is set on Record A. > >To Asvin, you cannot set locks in the same sequence every time. >This is because, in a sufficiently complex system you will have changes to >Customer's possibly affecting Orders, Inventory, Payables... >You can then have changes to Inventory possibly affecting Orders, Customers, >Receivables... >You can then have changes to Receivables, affecting Orders, Customers, >Inventory... >You can then have changes to Sales Reps affecting Customers, Orders, Payroll... > >The route from A to E is not the same as the route from B to G and then back >to C. > >So that's another problem. > >It seems like some of you have only ever worked on rather simple systems, >built by yourselves :) >Try working on systems that have been accreting for twenty years, and built by >sixteen other programmers over that time period. > >There is no simple deterministic way to avoid deadly embraces through code >alone. > > > >-----Original Message----- >From: David A. Green <dgr...@dagconsulting.com> >To: 'U2 Users List' <u2-users@listserver.u2ug.org> >Sent: Wed, Oct 26, 2011 6:42 am >Subject: Re: [U2] Avoiding deadly embraces > > >I find the best practice is to try and lock and read all the necessary >omponents before the first update. That way if an item we need to update >s we go along is unavailable we catch it up front and don't get "stuck". >r if you have TRANSACTION PROCESSING in place you can just to an ABORT. >I would also never just READU but do the RECORDLOCK or the READU with the >OCKED clause to be able to control program flow. You can send messages to >hose users that have the locked items even a text message or email. If you >re in a nightly batch process then do as another suggested and keep a list >f IDs and try to process them again at the end. Send an exception report >ia email to the ones in charge. >Set inactivity timeouts on record updates that require user intervention. >t would be awfully sad if Shipping can't ship because a Customer Service >ep was going to update the customers email and then got called away. >Something else that helps, keep the transactional data in a separate file >han the master record. For instance the Last_Shipped data shouldn't be in >he same record as the Customer's Address and email. This way the customer >creen can show the data in a "view only" mode with no need to lock the >ecord that the shipping department will need to update to do its job. >David A. Green >480) 813-1725 >AG Consulting > >______________________________________________ >2-Users mailing list >2-us...@listserver.u2ug.org >ttp://listserver.u2ug.org/mailman/listinfo/u2-users > >_______________________________________________ >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
