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<[email protected]>
To: U2 Users List<[email protected]>
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.
cds
On 10/25/2011 12:27 PM, 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
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
