To: Charles Stevenson
Cc: U2 Users List
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
I hate to bring it up after 50+ responses over 4 days, but . . .
Did anyone ever actually run my little test?
On something other than my UV10.2/Win? Unix? Before
Stevenson
Cc: U2 Users List
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
I hate to bring it up after 50+ responses over 4 days, but . . .
Did anyone ever actually run my little test?
On something other than my UV10.2/Win? Unix? Before UV10.2?
Knowing
I hate to bring it up after 50+ responses over 4 days, but . . .
Did anyone ever actually run my little test?
On something other than my UV10.2/Win? Unix? Before UV10.2?
Knowing that would help me assess the size age of our problem.
I still think that in times past, a waiterfor a lockvia
to set.
That's the problem.
-Original Message-
From: Charles Stevensonstevenson.c...@gmail.com
To: U2 Users Listu2-users@listserver.u2ug.org
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
Accountants... How about a ER doc waiting on lab results for cardiac enzymes? I
can hear it now: Sorry Doc, something else locked the record. Your patient's
test request was skipped so we could implement a trivial solution that was
suggested for deadly embrace. Try again, and hope for the best
Come on, get real.
Do you suggest the deadly embrace would be better and he would get his
results any quicker?
And anyway, an ER doc not getting his lab results because of a mass
update process running as a phantom encountering a locked record?
And who would hold a lock on those lab results
I'm suggesting that blinding skipping records is a HORRIBLE idea, and in our
case, potentially life threatening - literally. You need to get real with your
suggestion that coding for deadly embrace situations is a very easy solution
(your words). Not every phantom is a mass update. The IS
I never said anything about blindly (I guess that's what you meant)
skipping records.
I suggested writing the locked record ids somewhere else and process
them later for Wills not necessarily life-threatening sales rep update
phantom.
I at least don't feel threatened by accountants.
If
On 10/26/2011 7:45 AM, Robert Porter wrote:
Accountants... How about a ER doc waiting on lab results for cardiac
enzymes? I can hear it now: Sorry Doc, something else locked the
record. Your patient's test request was skipped so we could implement
a trivial solution that was suggested for
] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Why the 'deadly embrace' issue
From: Wjhonson wjhon...@aol.com
To: u2-users@listserver.u2ug.org; sfr192...@yahoo.com
Sent: Monday, October 24, 2011 8:42 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when
Yes.
Today, deadly embraces can be avoided via LOCKED clauses.
In days of yore, Pick's READU syntax did not allow a LOCKED clause.
BTW, I advocate 2 Programming Standards:
1. If a lock is taken (READU, RECORDLOCKU, FILELOCK, etc.), a
LOCKED clause must be present.
2. A lock must be
waiters when there are writes w/o
explicit readu.
Yes.
Today, deadly embraces can be avoided via LOCKED clauses.
In days of yore, Pick's READU syntax did not allow a LOCKED clause.
BTW, I advocate 2 Programming Standards:
1. If a lock is taken (READU, RECORDLOCKU, FILELOCK, etc.), a
LOCKED
What if you were writing to an empty file?
Rich
- Original Message -
From: Mecki Foerthmann mec...@gmx.net
To: u2-users@listserver.u2ug.org
Sent: Monday, October 24, 2011 6:30:08 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Now why would
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 solution
to the problem, which troubles all multi-table, multi-user database
environments.
Perhaps we
writing to an empty file?
Rich
- Original Message -
From: Mecki Foerthmannmec...@gmx.net
To: u2-users@listserver.u2ug.org
Sent: Monday, October 24, 2011 6:30:08 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Now why would anybody want to use
Oh yes there is a very easy solution.
If you write a mass update process like in your example you skip the
records with a lock and write them to an error log file.
That way you never end up in a deadly embrace.
After you finished the mass update you can then check for skipped
records and
you
know quite clearly with loud noises and waving of arms.
-Original Message-
From: Mecki Foerthmann mec...@gmx.net
To: u2-users u2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 10:58 am
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu
: Mecki Foerthmannmec...@gmx.net
To: u2-usersu2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 10:58 am
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Oh yes there is a very easy solution.
f you write a mass update process like in your example you
I know I'll write a phantom to monitor the phantom and write an error log read
by a third phantom!
I'll be at the top of the matrix in six years!
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
You could do it all in one program and run only one phantom, but of
course you can make it a lot more difficult if you want too.
KISS
On 25/10/2011 20:13, Wjhonson wrote:
I know I'll write a phantom to monitor the phantom and write an error log read
by a third phantom!
I'll be at the top of
Sent: Tue, Oct 25, 2011 1:30 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
You could do it all in one program and run only one phantom, but of
ourse you can make it a lot more difficult if you want too.
ISS
n 25/10/2011 20:13, Wjhonson wrote:
I
On 10/24/2011 4:11 PM, Charles Stevenson wrote:
--- [snip] ---
I have not yet explored what the deadlock daemon does.
Deadlock daemon ignores these WRITEs w/o explicit locking before hand.
I ran these 2 pgms simultaneously so that they both tried to lock or
write the lock that the other held.
stevenson.c...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 3:12 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
On 10/24/2011 4:11 PM, Charles Stevenson wrote:
--- [snip] ---
I have not yet explored what the deadlock
?
But if there is explicit READUs in both processes, that one of them will fail
in 20 minutes?
-Original Message-
From: Charles Stevensonstevenson.c...@gmail.com
To: U2 Users Listu2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 3:12 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when
List u2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 4:15 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
English is my 1st language, but that doesn't mean I'm good at it.
et me try again.
1. If either (or both) of these have WRITEs without
with them when they occur.
-Original Message-
From: Charles Stevensonstevenson.c...@gmail.com
To: U2 Users Listu2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 4:15 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
English is my 1st language
While Will's articledoes give a good, clear example of a deadly embrace,
and remediating faulty code is not trivial, the solution is conceptually
trivial 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
: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Properly programmed locked clauses are exactly the means by which one
lways avoids deadlocks.
can think of no example where that would not work, including your
arlier example.
As an example, I have added LOCKED
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
I don't know about UV but in UD, LIST.QUEUE shows waiters.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson
Sent: Monday, October 24, 2011 5:12 PM
To: U2 Users List
Subject: [U2] [UV] LIST.READU
I would think that because you are not trying to obtain the lock in a
WRITE statement, it would not be classified as a waiter. True, it's
waiting because of the lock but by not trying to obtain the lock, it's
only waiting for the blockage to clear. If it were to be classified as
a waiter then I
Now why would anybody want to use a WRITE without a READU?
I can possibly understand that somebody would want to do it with a
WRITEV (i.e writing a flag on a record) but WRITE?
And WRITE totally ignoring locking would be outright stupid.
On 24/10/2011 22:28, Woodward, Bob wrote:
I would think
The EVERY option on the LIST.READU shows the READ WAITERS.
I remember from when I was digging into the universe performance counters that
I enquired about this. The feedback I got was that there is nothing in UV that
shows the WRITE WATIERS your test is creating.
-Original Message-
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki
Foerthmann
Sent: Monday, October 24, 2011 3:30 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are
writes w/o explicit readu.
Now why would anybody want to use a WRITE without a READU
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Oh I agree! I was just thinking round-robin that if we're going to talk
about adding a LOCKED clause to the WRITE statement, matching the
structure of READU, then we ought to have a WRITEU, too. Didn't say
For the record, UV Basic's WRITE command does allow a LOCKED clause.
Which, of course, only applies in the ugly case where the lock was not
already held.
That doesn't imply that the legacy pre-UniVerse code actually has WRITE
LOCKED clauses.
On 10/24/2011 4:28 PM, Woodward, Bob wrote:
I
Mecki,
Point taken, but I didn't say anything about WANTing to do it that way.
This is existing software I'm trying to what's important to fix first.
Because there is a sort of implicit behind-the-scenes wait-for-then-lock
that happens on any WRITE to a record that is not explicitly (i.e.,
Maybe UD is where I am remembering this from.
On 10/24/2011 4:19 PM, Dave Davis wrote:
I don't know about UV but in UD, LIST.QUEUE shows waiters.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson
] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Oh I agree! I was just thinking round-robin that if we're going to talk
about adding a LOCKED clause to the WRITE statement, matching the
structure of READU, then we ought to have a WRITEU, too. Didn't say I
liked
: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Come to think of it, I think customizing CSC's MHC s/w was the 1st time
ever fought this fight.
Before that, I had always programmed under a standard that demanded a
EADU before a WRITE. And every READU
Why the 'deadly embrace' issue
From: Wjhonson wjhon...@aol.com
To: u2-users@listserver.u2ug.org; sfr192...@yahoo.com
Sent: Monday, October 24, 2011 8:42 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
20 points
41 matches
Mail list logo