You are right, you don't always know in advance which records you need to lock. If the processes are human controlled this can be solved by letting each user know who is locking whom out and they can solve the problem hopefully themselves. If phantom processes are doing this you don't have this option and you may have to employ the error log option or in case of a single file the loop with the sleep or even a combination of the two. If it is really "hairy" you may have to use transactions and don't commit until all records have been written. If a locking issue hasn't been resolved within such and such a time just release all locks and start again. So far I never had to do that, but AFAIK UniBasic has that feature and if you have so much trouble with phantoms locking each other out you should probably look at that option too.
Or maybe ask yourself if you really need that many phantoms?
There is no standard solution for every case but with a bit of thought every deadlock situation can be avoided or solved. In my experience locking problems are caused to 99% by users sitting in maintenance screens while they are doing something else like playing with spread sheets, sitting in meetings or go home without logging off.
User A gets a message that he can't proceed because user B holds a lock.
If he tries to ring user B and can't reach him he rings IT and I kick user B out ;-).
Simple as that! Happens about once a week.
I can live with that, but if it would be happening more frequently or with phantoms I would do something about it. In any case if you use READU use the locked clause because only then you have the option to bail out and avoid a deadlock.

On 26/10/2011 01:36, Wjhonson wrote:
It is not possible to know in advance all the locks you may wish to set.
That's the problem.

-----Original Message-----
From: Charles Stevenson<>
To: U2 Users List<>
Sent: Tue, Oct 25, 2011 5:22 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes w/o 
explicit readu.

While Will's articledoes give a good, clear example of a deadly embrace,
nd remediating faulty code is not trivial, the solution is conceptually
rivial and it is exactly the LOCKED clause that saves us.
If you write new code, deadlocks are easy to prevent.
Testing is non-trivial. It generally requires load or stress testing
here mutiple processes vie for the same locks.
In a nutshell: you shouldn't begin writing ANY part of a logical
ransaction until you own ALL necessary locks.  LOCKED clauses help you
rap cases where you can't get one of those needed locks, allowing you
o release all other related locks, (freeing up everything so the
ompeting process can finish its work), then you try again.   No
eadlocks.  QED.
My problem posed at the start of this thread represents a conceptually
rivial project but it will include retrofitting this anti-deadlock
ogic.  Non-trivial hours.  Opportunity costs.  More consistent data!
All MV platforms support this same solution.
If someone else wants to explain it in further detail for the newbies,
lease, be my guest.
On 10/25/2011 12:27 PM, Wjhonson wrote:
  This is deadly embrace

  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

  Perhaps we should start a new thread to discuss various approaches to the
  U2-Users mailing list

2-Users mailing list

U2-Users mailing list
U2-Users mailing list

Reply via email to