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, 
You can then have changes to Receivables, affecting Orders, Customers, 
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 
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 

-----Original Message-----
From: David A. Green <>
To: 'U2 Users List' <>
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

U2-Users mailing list

Reply via email to