Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
The answer for which I was looking was that the Locked clause was introduced. It was not original. -Original Message- From: Paul Wilson sfr192...@yahoo.com To: Wjhonson wjhon...@aol.com; u2-users u2-users@listserver.u2ug.org Sent: Mon, Oct 24, 2011 6:01 pm Subject: Re: [U2] [UV] 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 there are writes w/o explicit readu. 20 points to anyone who is old enough to remember *why* we couldn't rely on the Locked clause. -Original Message- From: Charles Stevenson stevenson.c...@gmail.com To: Paul Wilson sfr192...@yahoo.com; U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Oct 24, 2011 5:28 pm Subject: 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 I ever fought this fight. Before that, I had always programmed under a standard that demanded a READU before a WRITE. And every READU needed a LOCKED clause. cds On 10/24/2011 6:57 PM, Paul Wilson wrote: That little company called CSC does/did not use readu's - they put login id in field 1 and used that for a 'locking' situation. From: Woodward, Bobbob_woodw...@k2sports.com To: U2 Users Listu2-users@listserver.u2ug.org Sent: Monday, October 24, 2011 7:06 PM 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 I liked the idea -Original Message- From: u2-users-boun...@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? 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 locking. Just my guess, though. BobW -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 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list
Re: [U2] [UV] LIST.READU EVERY's 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 clause must be present. 2. A lock must be set explicitly before any update may be attempted. cds On 10/24/2011 8:01 PM, Paul Wilson wrote: Why the 'deadly embrace' issue From: Wjhonsonwjhon...@aol.com 20 points to anyone who is old enough to remember *why* we couldn't rely on the Locked clause. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Deadly Embraces cannot be avoided by use of a LOCKED clause. That's not what it means. -Original Message- From: Charles Stevenson stevenson.c...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, Oct 25, 2011 6:29 am Subject: Re: [U2] [UV] LIST.READU EVERY's 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 clause must be present. 2. A lock must be set explicitly before any update may be attempted. cds On 10/24/2011 8:01 PM, Paul Wilson wrote: Why the 'deadly embrace' issue From: Wjhonsonwjhon...@aol.com 20 points to anyone who is old enough to remember *why* we couldn't rely on the Locked clause. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
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 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 locking. Just my guess, though. BobW -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 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
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 should start a new thread to discuss various approaches to the issue. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Firstly a file isn't empty any more after the first WRITE. Secondly we have item and not file locking so if the file is empty or not is irrelevant. And last but not least only if you have exclusive use of a work file for instance you may not have to worry about locks and waiting since you are holding the lock anyway and nobody else should be able to put one on it. But since with lousy programming this is still possible following the standard 'Never write without a prior lock' just makes sense. Better safe than sorry! On 25/10/2011 17:07, Sammartino, Richard wrote: What if you were 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 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 locking. Just my guess, though. BobW -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 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
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 update them later. Or with the LOCKED clause you can let both parties know who is locking whom out and resolve the deadlock amicably by getting the sales person to exit the sales rep screen and file the customer record in your example. Ideally you should use a subroutine that tells you who is locking you out instead of READUs anyway. Mecki On 25/10/2011 18:27, 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 solution to the problem, which troubles all multi-table, multi-user database environments. Perhaps we should start a new thread to discuss various approaches to the issue. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Your second solution only works if one of the processes is controlled by a human. I've encountered deadly embraces between two phantom routines. Your first solution works, if we have the luxury of skipping locked records. Some update routines, don't have that luxury as most accountants will let 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. Oh yes there is a very easy solution. f you write a mass update process like in your example you skip the ecords with a lock and write them to an error log file. hat way you never end up in a deadly embrace. fter you finished the mass update you can then check for skipped ecords and update them later. Or with the LOCKED clause you can let both parties know who is locking hom out and resolve the deadlock amicably by getting the sales person o exit the sales rep screen and file the customer record in your xample. Ideally you should use a subroutine that tells you who is ocking you out instead of READUs anyway. Mecki On 25/10/2011 18:27, 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
So you just examine the errors at the end of the process and fix them automatically. The accountants will never know ;-) Where there is a will there is a solution! On 25/10/2011 19:20, Wjhonson wrote: Your second solution only works if one of the processes is controlled by a human. I've encountered deadly embraces between two phantom routines. Your first solution works, if we have the luxury of skipping locked records. Some update routines, don't have that luxury as most accountants will let you know quite clearly with loud noises and waving of arms. -Original Message- From: 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 skip the ecords with a lock and write them to an error log file. hat way you never end up in a deadly embrace. fter you finished the mass update you can then check for skipped ecords and update them later. Or with the LOCKED clause you can let both parties know who is locking hom out and resolve the deadlock amicably by getting the sales person o exit the sales rep screen and file the customer record in your xample. Ideally you should use a subroutine that tells you who is ocking you out instead of READUs anyway. Mecki On 25/10/2011 18:27, 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
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 http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Can anyone help explain this behavior or offer a workaround that saves me from handling it with line counters and printing my own headings?Cheers,Kebbon ___ Perry's approach is the correct one. If you want to know what's happening ... Because you're printing from within your own program, the Q to quit code is executing at the same EXECUTE level as your program. And guess what - the quit terminates the current EXECUTion level! So Perry's comment about EXECUTing a program to do the list-and-print is the right one. BUT - *a* *couple* *of* gotchas! If you write a program that assumes there's a select list (a sensible approach?) the select list is not always (iirc) passed between execute levels. That's caught plenty of people in the past. And - This is the point where PERFORM and EXECUTE differ. They're almost interchangeable, but not here, and I think it's both product and flavour dependant. Probably EXECUTE always creates a new execution level, but iirc Prime didn't have the concept of execution levels, so PERFORM didn't create a new one :-) Anyways, suck it and see, but at least you now know the what and the why. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
And... when you prematurely quit from an execution level which *had* been processing a select list your select list is not thrown away. Which is annoying. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
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 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 the matrix in six years! ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
I'd strongly suggest using the Unibasic SELECT file TO listname instead of EXECUTE SELECT filename selection criteria Then you just specify your selection criteria inside your loop. A few advantages that I've personally experienced, but there are probably more: The READNEXT begins immediately (does not wait for the whole file to be checked) You can nest your SELECTS (not that this is an ethical, but you can) You're not dependent on the accuracy of the dictionary If your selection criteria is part of the key, you don't even have to read the record if the key element fails the selection And you can write a cool little subroutine that keeps the human accurately informed as to the progress and estimated time of completion of their program The next-to-last one may depend on Unidata vs. Universe. I understand that Unidata only 'fetches' the key in the READNEXT while I believe Universe grabs both the key and record, due to the construct of the database. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, October 25, 2011 4:08 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniBasic Question And... when you prematurely quit from an execution level which *had* been processing a select list your select list is not thrown away. Which is annoying. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
It's always simple when you are programming for yourself. Once you start programming for contingencies, exceptions, and PDWT (people doing weird things), it's get complicated quickly. -Original Message- From: Mecki Foerthmann mec...@gmx.net To: u2-users u2-users@listserver.u2ug.org 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 know I'll write a phantom to monitor the phantom and write an error log read y a third phantom! I'll be at the top of the matrix in six years! ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Dave The next-to-last one may depend on Unidata vs. Universe. I understand that Unidata only 'fetches' the key in the READNEXT while I believe Universe grabs both the key and record, due to the construct of the database. I believe that is the case in Unidata. A SELECT returns a list of IDs. That's why your recommendation was confusing me. In the Unidata environment, I would have to read every record in order to apply the filter in the loop. In a case where only a few records are selected from a large file, this would create a lot of unnecessary disk activity. Also, you would not be able to SORT the order of the IDs. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Unless you know the keys to the records you're selecting, even the EXECUTE SELECT ... is going to have to read each record, how else would it know which records to throw out? My point is, if one of your selection criteria were in the key, then my method bypasses the need to read the record if the key element fails its test. I concede the sort, however some relatively simple 'table' management can easily remedy that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of charles_shaf...@ntn-bower.com Sent: Tuesday, October 25, 2011 4:53 PM To: U2 Users List Subject: Re: [U2] UniBasic Question Dave The next-to-last one may depend on Unidata vs. Universe. I understand that Unidata only 'fetches' the key in the READNEXT while I believe Universe grabs both the key and record, due to the construct of the database. I believe that is the case in Unidata. A SELECT returns a list of IDs. That's why your recommendation was confusing me. In the Unidata environment, I would have to read every record in order to apply the filter in the loop. In a case where only a few records are selected from a large file, this would create a lot of unnecessary disk activity. Also, you would not be able to SORT the order of the IDs. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Unless you know the keys to the records you're selecting, even the EXECUTE SELECT ... is going to have to read each record, how else would it know which records to throw out? SELECT is definitely faster than EXECUTE SELECT... and I try and use it first. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. On Tue, Oct 25, 2011 at 5:14 PM, charles_shaf...@ntn-bower.com wrote: Unless you know the keys to the records you're selecting, even the EXECUTE SELECT ... is going to have to read each record, how else would it know which records to throw out? SELECT is definitely faster than EXECUTE SELECT... and I try and use it first. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
There are key differences between the two types of selects. The EXECUTE SELECT... guarantees you access all the records that fit your criteria at the moment of the execute. The BASIC SELECT processes node by node of the datafile which allows for the possibility of records being added, deleted, or even just plain skipped in the case of a group move of a dynamic file, between the start of your program execution and the end of its execution. Granted, most of the time it's a non-issue because the time involved is pretty small. As long as you're aware of this difference and don't blindly think the two selects are identical in execution, then you should be okay. Also, I'd agree with the statement that the BASIC SELECT is faster... TO PROCESS THE FIRST TRANSACTION. But for the total execution time of any given run of the whole process, I think you'll find it's pretty darn close with only a slight difference. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of charles_shaf...@ntn-bower.com Sent: Tuesday, October 25, 2011 2:14 PM To: U2 Users List Subject: Re: [U2] UniBasic Question Unless you know the keys to the records you're selecting, even the EXECUTE SELECT ... is going to have to read each record, how else would it know which records to throw out? SELECT is definitely faster than EXECUTE SELECT... and I try and use it first. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
True on UV, too. Compare output of these using EXPLAIN keyword: LIST FILE WITH indexed_field = soemthing EXPLAIN LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX Or forget EXPLAIN, but do it with a large file and notice the speed differnce. On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Add a second selection criteria and the benefit of the index is washed out. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Tuesday, October 25, 2011 2:39 PM To: U2 Users List Subject: Re: [U2] UniBasic Question True on UV, too. Compare output of these using EXPLAIN keyword: LIST FILE WITH indexed_field = soemthing EXPLAIN LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX Or forget EXPLAIN, but do it with a large file and notice the speed differnce. On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
I think we are bike-shedding this now :) I seem to recall that if the indexed field is _before_ the non indexed field, its benefit is not lost. I have not looked close at that in a long time. On Tue, Oct 25, 2011 at 5:42 PM, Woodward, Bob bob_woodw...@k2sports.com wrote: Add a second selection criteria and the benefit of the index is washed out. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Tuesday, October 25, 2011 2:39 PM To: U2 Users List Subject: Re: [U2] UniBasic Question True on UV, too. Compare output of these using EXPLAIN keyword: LIST FILE WITH indexed_field = soemthing EXPLAIN LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX Or forget EXPLAIN, but do it with a large file and notice the speed differnce. On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Yes yes and no. If you execute a SSELECT on an indexed field, and don't specify NO.INDEX and do NOT refer at all to any other fields in the file, then index does NOT read the record to see if it even actually exists. It just retrieves the list of keys from the index. If you specific a SSELECT on an indexed field and ALSO specify some other field criteria, then the select is *supposed* to use the index field FIRST to retrieve the list of keys and ONLY THEN read each record to see whether it matches the other criteria. So the first pass if you will should be lightning fast, but then IF your other criteria makes it traverse the majority of the file you are in for big Trouble with a T that rhymes with P that stands for Pool. The reason you are in for trouble in this last case, is that traversing the majority of the file causes Disk Thrashing which is bad very bad very very bad. It causes this because you are forcing the system to reference the records out-of-disk-order. So it's jumping, jumping, jumping all over the disk in a helter skelter summer swelter. You want to avoid that. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
RetrieVe will use an index if it can, regardless of the order of the selection criteria ( if not select list is already active). RetrieVe will now do intersections of index reults if 2 indexed selection criteria are specified. I'm not sure when or how good it does that. NO.OPTIMIZE can override these attempts by RetrieVe. NO.INDEX will prevent indexes being used. On 10/25/2011 5:00 PM, Steve Romanow wrote: I think we are bike-shedding this now :) I seem to recall that if the indexed field is _before_ the non indexed field, its benefit is not lost. I have not looked close at that in a long time. On Tue, Oct 25, 2011 at 5:42 PM, Woodward, Bob bob_woodw...@k2sports.com wrote: Add a second selection criteria and the benefit of the index is washed out. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Tuesday, October 25, 2011 2:39 PM To: U2 Users List Subject: Re: [U2] UniBasic Question True on UV, too. Compare output of these using EXPLAIN keyword: LIST FILE WITH indexed_field = soemthing EXPLAIN LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX Or forget EXPLAIN, but do it with a large file and notice the speed differnce. On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
But you are potentially reducing your input set for the 2nd criteria by a large margin correct? I've never considered alt key + non-indexed usage to create disk thrash. When you select on an alternate key index, you are reading the file, but (in Udt at least) an X_myfile binary file. So you are doing a direct read for the matching keys. It has no knowledge of the file layout. On Tue, Oct 25, 2011 at 6:01 PM, Wjhonson wjhon...@aol.com wrote: Yes yes and no. If you execute a SSELECT on an indexed field, and don't specify NO.INDEX and do NOT refer at all to any other fields in the file, then index does NOT read the record to see if it even actually exists. It just retrieves the list of keys from the index. If you specific a SSELECT on an indexed field and ALSO specify some other field criteria, then the select is *supposed* to use the index field FIRST to retrieve the list of keys and ONLY THEN read each record to see whether it matches the other criteria. So the first pass if you will should be lightning fast, but then IF your other criteria makes it traverse the majority of the file you are in for big Trouble with a T that rhymes with P that stands for Pool. The reason you are in for trouble in this last case, is that traversing the majority of the file causes Disk Thrashing which is bad very bad very very bad. It causes this because you are forcing the system to reference the records out-of-disk-order. So it's jumping, jumping, jumping all over the disk in a helter skelter summer swelter. You want to avoid that. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
That's too bold a rule of thumb for me, Bob. I will grant you that indexes need to be well thought out. It also depends on what percent of the entire file you retrieve via the index. If it is too large, a filescan via basic select or NO,.INDEX keyword is quicker. Bob also made a comment about relative speed of retrieve's select vs. basic. I must admit that I have often been pleasantly surprised at how fast retrieve is even when it looks like I ought to be able to do it faster in basic. On 10/25/2011 4:42 PM, Woodward, Bob wrote: Add a second selection criteria and the benefit of the index is washed out. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Tuesday, October 25, 2011 2:39 PM To: U2 Users List Subject: Re: [U2] UniBasic Question True on UV, too. Compare output of these using EXPLAIN keyword: LIST FILE WITH indexed_field = soemthing EXPLAIN LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX Or forget EXPLAIN, but do it with a large file and notice the speed differnce. On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
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 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. Ran with lines 6/7 variously commented out or left in. W12 W21 01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21' 02: OPEN 'CDSTMP' TO F ELSE STOP| OPEN 'CDSTMP' TO F ELSE STOP 03: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL 04: INPUT DUM | INPUT DUM 05: CRT TIMEDATE():'...': | CRT TIMEDATE():'...': 06: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL 07: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1' 08: CRT TIMEDATE() | CRT TIMEDATE() They invariably entered a deadly embrace, both processes waiting on the other, but the deadlock daemon ignored it if there is no explicit readu. Instead one of them aborted with a write failure in 20 minutes (the default, but configurable action), then the other then continued happily. I hope no one but I ever cares about this. Moral of the story: Explicitly lock before you update. cds On 10/24/2011 4:11 PM, Charles Stevenson wrote: 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
When you read the index, you are doing a direct read. When on your second pass you are reading some other field as part of your select criteria, you are using the index, which is layed down sequentially, to access a non-sequential file, causing thrashing. In other words, in order to determine if your zip code list also has the situation foreign country or whatever, you are reading each record, which you've picked up quickly from an index, but now you're drilling down to each individual record to check this second criteria. When you do that read, you are not doing it, in any manner like the way the records are layed on the disk. That causes thrashing. -Original Message- From: Steve Romanow slestak...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, Oct 25, 2011 3:07 pm Subject: Re: [U2] UniBasic Question But you are potentially reducing your input set for the 2nd criteria y a large margin correct? I've never considered alt key + non-indexed usage to create disk thrash. When you select on an alternate key index, you are reading the file, ut (in Udt at least) an X_myfile binary file. So you are doing a irect read for the matching keys. It has no knowledge of the file ayout. On Tue, Oct 25, 2011 at 6:01 PM, Wjhonson wjhon...@aol.com wrote: Yes yes and no. If you execute a SSELECT on an indexed field, and don't specify NO.INDEX and o NOT refer at all to any other fields in the file, then index does NOT read he record to see if it even actually exists. It just retrieves the list of eys from the index. If you specific a SSELECT on an indexed field and ALSO specify some other ield criteria, then the select is *supposed* to use the index field FIRST to etrieve the list of keys and ONLY THEN read each record to see whether it atches the other criteria. So the first pass if you will should be lightning ast, but then IF your other criteria makes it traverse the majority of the file ou are in for big Trouble with a T that rhymes with P that stands for Pool. The reason you are in for trouble in this last case, is that traversing the ajority of the file causes Disk Thrashing which is bad very bad very very bad. It causes this because you are forcing the system to reference the records ut-of-disk-order. So it's jumping, jumping, jumping all over the disk in a elter skelter summer swelter. You want to avoid that. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
I believe that it is incorrect that it will intersect indexes. I understand that some people think this might be preferable, but I do not believe this logic has ever been coded in. -Original Message- From: Charles Stevenson stevenson.c...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, Oct 25, 2011 3:08 pm Subject: Re: [U2] UniBasic Question RetrieVe will use an index if it can, regardless of the order of the election criteria ( if not select list is already active). etrieVe will now do intersections of index reults if 2 indexed election criteria are specified. 'm not sure when or how good it does that. O.OPTIMIZE can override these attempts by RetrieVe. O.INDEX will prevent indexes being used. On 10/25/2011 5:00 PM, Steve Romanow wrote: I think we are bike-shedding this now :) I seem to recall that if the indexed field is _before_ the non indexed field, its benefit is not lost. I have not looked close at that in a long time. On Tue, Oct 25, 2011 at 5:42 PM, Woodward, Bob bob_woodw...@k2sports.com wrote: Add a second selection criteria and the benefit of the index is washed out. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Tuesday, October 25, 2011 2:39 PM To: U2 Users List Subject: Re: [U2] UniBasic Question True on UV, too. Compare output of these using EXPLAIN keyword: LIST FILE WITH indexed_field = soemthing EXPLAIN LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX Or forget EXPLAIN, but do it with a large file and notice the speed differnce. On 10/25/2011 4:29 PM, charles_shaf...@ntn-bower.com wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. Are you saying that when there is an index, the system does not need to read the record at all? It just gets the SELECT list from the index? Is this only true in Unidata? ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
I dont' quite follow that. Are you stating that if there is no explicit READU that both processes will complete without the deadlock deamon? But if there is explicit READUs in both processes, that one of them will fail in 20 minutes? -Original Message- From: Charles Stevenson 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 daemon does. Deadlock daemon ignores these WRITEs w/o explicit locking before hand. ran these 2 pgms simultaneously so that they both tried to lock or rite the lock that the other held. an with lines 6/7 variously commented out or left in. W12 W21 01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21' 2: OPEN 'CDSTMP' TO F ELSE STOP| OPEN 'CDSTMP' TO F ELSE STOP 3: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL 4: INPUT DUM | INPUT DUM 5: CRT TIMEDATE():'...': | CRT TIMEDATE():'...': 6: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL 7: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1' 8: CRT TIMEDATE() | CRT TIMEDATE() hey invariably entered a deadly embrace, both processes waiting on the ther, but the deadlock daemon ignored it if there is no explicit readu. Instead one of them aborted with a write failure in 20 minutes (the efault, but configurable action), then the other then continued happily. hope no one but I ever cares about this. Moral of the story: Explicitly lock before you update. cds n 10/24/2011 4:11 PM, Charles Stevenson wrote: 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
On 25/10/11 22:22, Steve Romanow wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. SELECT *is* faster. Because it does far less work! EXECUTE SELECT needs to read the entire file to create a select list. SELECT merely reads group 0 to create a partial select list, then when it's exhausted goes on to group 1 and so on and so on. Which is BEST depends on what you want. Which is FASTER is always SELECT. (Oh - and while the poster didn't get it quite right, READNEXT is fast on UV, because while it doesn't pull the record into your program, because the key and data are stored together the mere act of accessing the key will cache the data at the same time). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Consider a sparse file. I have seen where a execute select is faster so I counter your AlwaysFaster claim. Like the previous poster said, it will always be fastest to start, but not always first to complete. On Oct 25, 2011 7:00 PM, Wols Lists antli...@youngman.org.uk wrote: On 25/10/11 22:22, Steve Romanow wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. SELECT *is* faster. Because it does far less work! EXECUTE SELECT needs to read the entire file to create a select list. SELECT merely reads group 0 to create a partial select list, then when it's exhausted goes on to group 1 and so on and so on. Which is BEST depends on what you want. Which is FASTER is always SELECT. (Oh - and while the poster didn't get it quite right, READNEXT is fast on UV, because while it doesn't pull the record into your program, because the key and data are stored together the mere act of accessing the key will cache the data at the same time). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
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. Let me try again. 1. If either (or both) of these have WRITEs without explicit readus ahead of time: -- the deadlock daemon seems to recognize the deadlock. -- If said WRITE command cannot gain a lock within 20 minutes it will error out. (That is the default behavior, but configurable.) -- So after 20 minutes (one of) the program(s) waiting on such a write will error out allowing the other to get the lock and continue. 2. If both programs have READUs: -- the deadlock deamon sees the condition and kills one of them. The solution for completely avoiding a deadlock is - as always - to properly deploy LOCKED clauses. On 10/25/2011 5:29 PM, Wjhonson wrote: I dont' quite follow that. Are you stating that if there is no explicit READU that both processes will complete without the deadlock deamon? 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 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 daemon does. Deadlock daemon ignores these WRITEs w/o explicit locking before hand. ran these 2 pgms simultaneously so that they both tried to lock or rite the lock that the other held. an with lines 6/7 variously commented out or left in. W12 W21 01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21' 2: OPEN 'CDSTMP' TO F ELSE STOP| OPEN 'CDSTMP' TO F ELSE STOP 3: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL 4: INPUT DUM | INPUT DUM 5: CRT TIMEDATE():'...': | CRT TIMEDATE():'...': 6: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL 7: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1' 8: CRT TIMEDATE() | CRT TIMEDATE() hey invariably entered a deadly embrace, both processes waiting on the ther, but the deadlock daemon ignored it if there is no explicit readu. Instead one of them aborted with a write failure in 20 minutes (the efault, but configurable action), then the other then continued happily. hope no one but I ever cares about this. Moral of the story: Explicitly lock before you update. cds n 10/24/2011 4:11 PM, Charles Stevenson wrote: 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
I reread my post and meant no disrespect Wols. I shouldnt post replies without considering twice. On Oct 25, 2011 7:00 PM, Wols Lists antli...@youngman.org.uk wrote: On 25/10/11 22:22, Steve Romanow wrote: I don't know if I agree that SELECT is faster. If you are using indexed fields, SELECT is definitely not the good choice. SELECT *is* faster. Because it does far less work! EXECUTE SELECT needs to read the entire file to create a select list. SELECT merely reads group 0 to create a partial select list, then when it's exhausted goes on to group 1 and so on and so on. Which is BEST depends on what you want. Which is FASTER is always SELECT. (Oh - and while the poster didn't get it quite right, READNEXT is fast on UV, because while it doesn't pull the record into your program, because the key and data are stored together the mere act of accessing the key will cache the data at the same time). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Thanks for that longer explanation, but you can't avoid deadlocks with LOCKED clauses. Maybe what you meant was something like You can try to think of some strategy to deal with them when they occur. -Original Message- From: Charles Stevenson stevenson.c...@gmail.com To: U2 Users 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 explicit readus head of time: - the deadlock daemon seems to recognize the deadlock. - If said WRITE command cannot gain a lock within 20 minutes it will rror out. (That is the default behavior, but configurable.) - So after 20 minutes (one of) the program(s) waiting on such a write ill error out allowing the other to get the lock and continue. 2. If both programs have READUs: - the deadlock deamon sees the condition and kills one of them. The solution for completely avoiding a deadlock is - as always - to roperly deploy LOCKED clauses. n 10/25/2011 5:29 PM, Wjhonson wrote: I dont' quite follow that. Are you stating that if there is no explicit READU that both processes will omplete without the deadlock deamon? But if there is explicit READUs in both processes, that one of them will fail n 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 there are writes w/o xplicit readu. 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. ran these 2 pgms simultaneously so that they both tried to lock or rite the lock that the other held. an with lines 6/7 variously commented out or left in. W12 W21 01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21' 2: OPEN 'CDSTMP' TO F ELSE STOP| OPEN 'CDSTMP' TO F ELSE STOP 3: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL 4: INPUT DUM | INPUT DUM 5: CRT TIMEDATE():'...': | CRT TIMEDATE():'...': 6: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL 7: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1' 8: CRT TIMEDATE() | CRT TIMEDATE() hey invariably entered a deadly embrace, both processes waiting on the ther, but the deadlock daemon ignored it if there is no explicit readu. Instead one of them aborted with a write failure in 20 minutes (the efault, but configurable action), then the other then continued happily. hope no one but I ever cares about this. Moral of the story: Explicitly lock before you update. cds n 10/24/2011 4:11 PM, Charles Stevenson wrote: 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 record. While Session B is waiting, does it show up as a waiter in LIST.READU EVERY? 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 'nope' 02: ***READU REC FROM F, 'DUMMY' ELSE NULL 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 746117947232860913 61163396 But when I comment out line 2, LIST.READU is silent. I have not yet explored what the deadlock daemon does. TIA, cds P.S. Yes, yes, Bad Form, Legacy Software, 20 min wait is configurable, . . . we can talk later. ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list
Re: [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 always avoids deadlocks. I can think of no example where that would not work, including your earlier example. As an example, I have added LOCKED clauses to the 2 pgms I listed below W12 W21. If you run the original versions and wait for both to get to the prompt before hittingenter to both, you can't help but always get a deadlock. If you run the LOCKED-clause-enabled versions, you can never get a deadlock. (Forget about the GOTOs. I wanted to keep it simple to read. You can do the same with LOOP-REPEAT.) CT CDS.BP W12 W21 W12 0001 CRT TIMEDATE(), 'W12' 0002 OPEN 'CDSTMP' TO F ELSE STOP 0003 RDUS: READU REC1 FROM F, 'W1' LOCKED 0004 SLEEP 1 ; * wait a bit 0005 GO RDUS 0006 END ELSE NULL 0007 INPUT DUM 0008 CRT TIMEDATE():'...': 0009 READU REC2 FROM F, 'W2' LOCKED 0010 RELEASE F, 'W1' 0011 SLEEP 1 ; * wait a bit 0012 GO RDUS 0013 END ELSE NULL 0014 WRITE TIME() TO F, 'W2' 0015 CRT TIMEDATE() W21 0001 CRT TIMEDATE(), 'W21' 0002 OPEN 'CDSTMP' TO F ELSE STOP 0003 RDUS: READU REC1 FROM F, 'W2' LOCKED 0004 SLEEP 1 ; * wait a bit 0005 GO RDUS 0006 END ELSE NULL 0007 INPUT DUM 0008 CRT TIMEDATE():'...': 0009 READU REC2 FROM F, 'W1' LOCKED 0010 RELEASE F, 'W2' 0011 SLEEP 1 ; * wait a bit 0012 GO RDUS 0013 END ELSE NULL 0014 WRITE TIME() TO F, 'W2' 0015 CRT TIMEDATE() On 10/25/2011 6:34 PM, Wjhonson wrote: Thanks for that longer explanation, but you can't avoid deadlocks with LOCKED clauses. Maybe what you meant was something like You can try to think of some strategy to deal 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, but that doesn't mean I'm good at it. et me try again. 1. If either (or both) of these have WRITEs without explicit readus head of time: - the deadlock daemon seems to recognize the deadlock. - If said WRITE command cannot gain a lock within 20 minutes it will rror out. (That is the default behavior, but configurable.) - So after 20 minutes (one of) the program(s) waiting on such a write ill error out allowing the other to get the lock and continue. 2. If both programs have READUs: - the deadlock deamon sees the condition and kills one of them. The solution for completely avoiding a deadlock is - as always - to roperly deploy LOCKED clauses. n 10/25/2011 5:29 PM, Wjhonson wrote: I dont' quite follow that. Are you stating that if there is no explicit READU that both processes will omplete without the deadlock deamon? But if there is explicit READUs in both processes, that one of them will fail n 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 there are writes w/o xplicit readu. 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. ran these 2 pgms simultaneously so that they both tried to lock or rite the lock that the other held. an with lines 6/7 variously commented out or left in. W12 W21 01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21' 2: OPEN 'CDSTMP' TO F ELSE STOP| OPEN 'CDSTMP' TO F ELSE STOP 3: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL 4: INPUT DUM | INPUT DUM 5: CRT TIMEDATE():'...': | CRT TIMEDATE():'...': 6: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL 7: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1' 8: CRT TIMEDATE() | CRT TIMEDATE() hey invariably entered a deadly embrace, both processes waiting on the ther, but the deadlock daemon ignored it if there is no explicit readu. Instead one of them aborted with a write failure in 20 minutes (the efault, but configurable action), then the other then continued happily. hope no one but I ever cares about this. Moral of the story: Explicitly lock before you update. cds n 10/24/2011 4:11 PM, Charles Stevenson wrote: 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
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, 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 generally requires load or stress testing where mutiple processes vie for the same locks. In a nutshell: you shouldn't begin writing ANY part of a logical transaction until you own ALL necessary locks. LOCKED clauses help you trap cases where you can't get one of those needed locks, allowing you to release all other related locks, (freeing up everything so the competing process can finish its work), then you try again. No deadlocks. QED. My problem posed at the start of this thread represents a conceptually trivial project but it will include retrofitting this anti-deadlock logic. 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, please, 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 solution to the problem, which troubles all multi-table, multi-user database environments. Perhaps we should start a new thread to discuss various approaches to the issue. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Your example fails. You are deliberately returning the user back to the beginning of a program deep in progress, or you are assuming we know in advance what locks might be set. Both of these are bad devices and assumptions. Are you really going to throw away your order entry clerk's last five minutes of typing without so much as a by your leave ? He is going to be very mad at you for that. -Original Message- From: Charles Stevenson stevenson.c...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Cc: Wjhonson wjhon...@aol.com Sent: Tue, Oct 25, 2011 5:21 pm Subject: Re: [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 clauses to the 2 pgms I listed below 12 W21. If you run the original versions and wait for both to get to the prompt efore hittingenter to both, you can't help but always get a deadlock. f you run the LOCKED-clause-enabled versions, you can never get a deadlock. (Forget about the GOTOs. I wanted to keep it simple to read. You can o the same with LOOP-REPEAT.) CT CDS.BP W12 W21 W12 001 CRT TIMEDATE(), 'W12' 002 OPEN 'CDSTMP' TO F ELSE STOP 003 RDUS: READU REC1 FROM F, 'W1' LOCKED 004 SLEEP 1 ; * wait a bit 005 GO RDUS 006 END ELSE NULL 007 INPUT DUM 008 CRT TIMEDATE():'...': 009 READU REC2 FROM F, 'W2' LOCKED 010 RELEASE F, 'W1' 011 SLEEP 1 ; * wait a bit 012 GO RDUS 013 END ELSE NULL 014 WRITE TIME() TO F, 'W2' 015 CRT TIMEDATE() W21 001 CRT TIMEDATE(), 'W21' 002 OPEN 'CDSTMP' TO F ELSE STOP 003 RDUS: READU REC1 FROM F, 'W2' LOCKED 004 SLEEP 1 ; * wait a bit 005 GO RDUS 006 END ELSE NULL 007 INPUT DUM 008 CRT TIMEDATE():'...': 009 READU REC2 FROM F, 'W1' LOCKED 010 RELEASE F, 'W2' 011 SLEEP 1 ; * wait a bit 012 GO RDUS 013 END ELSE NULL 014 WRITE TIME() TO F, 'W2' 015 CRT TIMEDATE() On 10/25/2011 6:34 PM, Wjhonson wrote: Thanks for that longer explanation, but you can't avoid deadlocks with LOCKED lauses. Maybe what you meant was something like You can try to think of some strategy o deal 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 xplicit 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 explicit readus head of time: - the deadlock daemon seems to recognize the deadlock. - If said WRITE command cannot gain a lock within 20 minutes it will rror out. (That is the default behavior, but configurable.) - So after 20 minutes (one of) the program(s) waiting on such a write ill error out allowing the other to get the lock and continue. 2. If both programs have READUs: - the deadlock deamon sees the condition and kills one of them. The solution for completely avoiding a deadlock is - as always - to roperly deploy LOCKED clauses. n 10/25/2011 5:29 PM, Wjhonson wrote: I dont' quite follow that. Are you stating that if there is no explicit READU that both processes will omplete without the deadlock deamon? But if there is explicit READUs in both processes, that one of them will ail n 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 there are writes /o xplicit readu. 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. ran these 2 pgms simultaneously so that they both tried to lock or rite the lock that the other held. an with lines 6/7 variously commented out or left in. W12 W21 01: CRT TIMEDATE(), 'W12' | CRT TIMEDATE(), 'W21' 2: OPEN 'CDSTMP' TO F ELSE STOP| OPEN 'CDSTMP' TO F ELSE STOP 3: READU REC1 FROM F, 'W1' ELSE NULL | READU REC2 FROM F, 'W2' ELSE NULL 4: INPUT DUM | INPUT DUM 5: CRT TIMEDATE():'...': | CRT TIMEDATE():'...': 6: *** READU REC2 FROM F, W2 ELSE NULL | READU REC1 FROM F, 'W1' ELSE NULL 7: WRITE TIME() TO F, 'W2' | WRITE TIME() TO F, 'W1' 8: CRT TIMEDATE() | CRT TIMEDATE() hey invariably entered a deadly embrace, both processes waiting on the
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
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 stevenson.c...@gmail.com To: U2 Users List u2-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 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
