That's not really relevant to what I said. It's not a question at all of the *number* of transactions or processes, nor how complex the business rules are. It's much more relevant to the complexity of the history of the software.
That someone would suggest that locks can be set in the same sequence in every case, illustrates the communication divide. -----Original Message----- From: Brian Leach <br...@brianleach.co.uk> To: U2 Users List <u2-users@listserver.u2ug.org> Sent: Wed, Oct 26, 2011 2:47 pm Subject: Re: [U2] Avoiding deadly embraces Will - you couldn't be more wrong in your last paragraph. FWIW Knowing Asvin and he systems he works on I can tell you they are anything but simple - highly omplex rules handling many hundreds of concurrent processes and millions of ransactions 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, hat'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 nother update to be triggered in some other record. You cannot know that in advance, that is, you cannot determine what the user ay do next, so you cannot set the lock in advance, but only at-the-time they ct, 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 ustomer's possibly affecting Orders, Inventory, Payables... You can then have changes to Inventory possibly affecting Orders, Customers, eceivables... You can then have changes to Receivables, affecting Orders, Customers, nventory... 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 . So that's another problem. It seems like some of you have only ever worked on rather simple systems, built y yourselves :) Try working on systems that have been accreting for twenty years, and built by ixteen other programmers over that time period. There is no simple deterministic way to avoid deadly embraces through code lone. -----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 ______________________________________________ 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
