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.,
properly) readu'd 1st, I expected it to show up in the LIST.READU's
"waiter" section. I was hoping to monitor that to triage how big a
problem it is in practice.
By the way, WRITEU & DELETEU will NOT preserve that "implicit" lock; it
only preserves an explicit lock that already exists.
Personally, I advocate a programming standard that insists on explicit
READU (or RECORDLOCKU) before updates & deletes. TRANSACTIONs demand it.
Furthermore, there should always be LOCKED clauses.
On 10/24/2011 5:30 PM, Mecki Foerthmann wrote:
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 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 would expect to see a LOCKED clause on the WRITE
statement like there is on the READU. For that matter, I'd expect to
see a WRITEU command as well and the standard WRITE to completely ignore
Just my guess, though.
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles
Sent: Monday, October 24, 2011 2:12 PM
To: U2 Users List
Subject: [U2] [UV] LIST.READU EVERY's "waiters" when there are writes
w/o explicit readu.
UV 10.2.10 on Windows is behaving differently from what I recall.
Are my expectations out of line?
Suppose Session A holds a readu lock; and Session B attempts a WRITE to
same record withOUT!!! 1st explicitly getting the readu lock.
Session B waits for Session A to release the lock before writing the
While Session B is waiting, does it show up as a "waiter" in LIST.READU
I expected so, but it doesn't.
Session A Session B
1A. ED VOC DUMMY
(this sets the readu lock.)
2A. (stay in editor) 2B. run this:
01: OPEN 'VOC' TO F ELSE STOPM
02: ***READU REC FROM F, 'DUMMY'
03: WRITE '' TO F, 'DUMMY'
3A. Within ED:
XEQ LIST.READU EVERY
If I UN-comment line 2, LIST.READU EVERY shows something like this:
Active Read Waiters: Owner Waiter
Device.... Inode.... Userno Userno
746117947 232860913 6116 3396
But when I comment out line 2, LIST.READU is silent.
I have not yet explored what the deadlock daemon does.
P.S. Yes, yes, "Bad Form", "Legacy Software", 20 min wait is
configurable, . . . we can talk later.
U2-Users mailing list