Re: [U2] Record Locks - How long should they last for? (Opinion)
READUO is just READ (keep an original copy of the record, to detect changes), at the end of your code perform the write. If you want to detect, and remediate any changes someone else made, read the record again, compare it to the original record (before the record was updated) and remediate the differences. The write will temporarily lock the record. Personally, optimistic locking is not an ideal method for performing updates. I know that is the way many DBs work but that doesn't make it right. Tom Whitmore RATEX Business Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ross Ferris Sent: Wednesday, July 13, 2011 10:47 PM To: U2 Users List Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) why haven't the MV DBMS vendors created a READUO Possibly in part because of the need to then have resolution mechanism for when 2 processes change the same data (assuming of course that the data wasn't, say, an accumulation total) -- what interface would you use telnet will not work nicely with the web app described, nor with someone using, say UOJ Still, extend a bit, and it could throw an error with the differences to be handled by whatever application layer -- but of course the real kicker in all of this is, and always has been, the wealth of legacy code that WOULDN'T use the new mechanism without a major rewrite and if you get to THAT point, refer to why U2 thread :-( Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, 14 July 2011 8:46 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ 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] Record Locks - How long should they last for? (Opinion)
Because it is just 2 lines of code anyway so why bother -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 13 July 2011 23:46 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3762 - Release Date: 07/13/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
WELL - optimistic lock testing is WAY more than 2 lines of code! You have to have a 'structure' to 'store' the original data image in, then on the write, check that image against a current version (that you DID hard lock) and if the same, write, if not fail. If you can do that in 2 lines of code, you're a better programmer than I am! LOL! But Tony's point was that you either have to 'code' for each kind of write to have one routine work from both standard locks or optimistic locks. That would add dozens of lines of code to each routine. Perhaps a more interesting example might be -- what if your business model would make it more efficient to move one of the files 'off world' to a SQL store on another machine?? If you 'called' a subroutine to do your reads and writes, those could actually handle that 'File A is now an SQL file while File B is still UniData' and handle that 'migration issue' with no changes to any business logic. When your program made a 'call' to read Key XYZ from File A, at one time it was a 'direct read' while now it's SQL query for that data to another machine -- the only program that changes is your 'READ' and 'WRITE' program being able to intercept and mangle the data such that the 'business logic' program just gets the MV record structure it was asking to retrieve. Just sort of a nifty idea. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen Sent: Thursday, July 14, 2011 7:28 AM To: 'U2 Users List' Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) Because it is just 2 lines of code anyway so why bother -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 13 July 2011 23:46 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3762 - Release Date: 07/13/11 ___ 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] Record Locks - How long should they last for? (Opinion)
On 14/07/11 13:40, David Wolverton wrote: Perhaps a more interesting example might be -- what if your business model would make it more efficient to move one of the files 'off world' to a SQL store on another machine?? If you 'called' a subroutine to do your reads and writes, those could actually handle that 'File A is now an SQL file while File B is still UniData' and handle that 'migration issue' with no changes to any business logic. When your program made a 'call' to read Key XYZ from File A, at one time it was a 'direct read' while now it's SQL query for that data to another machine -- the only program that changes is your 'READ' and 'WRITE' program being able to intercept and mangle the data such that the 'business logic' program just gets the MV record structure it was asking to retrieve. Going back donkeys years ... when I first started programming I wrote an accounts app. As far as the user was concerned the update appeared on the screen just fine - I used whatever data happened to be current. HOWEVER. Only when the user said transaction complete did I rerun the transaction, with locks (actually, files open read-write rather than just read), and commit the transaction. I know that doesn't always work well, especially if you want to reserve stock and stuff - the user won't want to order goods only to find that stocks have disappeared between creating the order and committing it. But there's an easy way round that - just have a stuff currently being ordered file - when accepting the order create a record for the user in this file, then check to see that there's stock for all orders currently being processed. Have some mechanism for cleaning out stale entries so crashed sessions don't hog all the stock. Just think outside the box, try and store the transaction in the web session, and only commit it once the user has said yes go ahead. If the session visible to the user shows data that's a couple minutes out of date, does that really matter? I know the answer could be yes, but usually it's no not at all. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
David, For your last point regarding accessing data from multiple places. -
i have done just that and a number of programmers use it to access data
that can be u2, sql, xml or csv in source - all with an open, read, write
call, and it is made easier with some nice equates so it all looks kind of
object orientated
In case you are interested here is an example
* program to open and read data from a file
$INCLUDE TBP Common.include;* COMMON INCLUDE
CALL global.setParams ;* SET SOME VARS
$INCLUDE TBP STDDATA.include ; I want to use a file called STDDATA so
include its include
IF STDDATA.open THEN
STDDATA.id = recid
IF STDDATA.read THEN
CRT STDDATA.record
STDDATA.ammount='10'
IF STDDATA.write THEN CRT Huzzah ELSE CRT Booo
END ELSE
CRT no rec
END
END ELSE
CRT 'Cannot open'
END
The STDDATA.include would look like
* STDDATA.include
* Standard include for STDDATA data File including object and open
* Use :-
* {filename}.FILE as the file variable
* {filename}.OPEN to open the file
* {filename}.id as the record id
* {filename}.record as the record
* {filename}.{property} for each attribute as defined in here
* {filename}.record.write to do a WRITE of the record
* {filename}.record.writeu to do a WRITEU of the record
* {filename}.record.read to do a READ of the record
* {filename}.record.readu to do a READU of the record
* {filename}.SELECT to select all rows
* Read operations use a generec file function which returns 0 or 1 so you
can use the else and then
* Write operations use a specific function that uses the above function so
again return codes can be used. Also
* the write may do index etc updates so they can be placed in the specific
function
* File operations are read and write and not matread/write as records on
this project are small.
*methods
DEFFUN FFileOperation(t1,t2,t3,t4,t5,t6,t7)
DEFFUN FSTDDATA.fileupdate(t1,t2,t3,t4,t5,t6)
EQU STDDATA.open LIT
'FFileOperation(O,STDDATA,STDDATA.FILE,,,0,Err)'
EQU STDDATA.record.read LIT
'FFileOperation(R,STDDATA,STDDATA.FILE,STDDATA.record,STDDATA.id,0,Err)'
EQU STDDATA.record.readu LIT
'FFileOperation(R,STDDATA,STDDATA.FILE,STDDATA.record,STDDATA.id,1,Err)'
EQU STDDATA.record.write LIT
'FFileOperation(W,STDDATA,STDDATA.FILE,STDDATA.record,STDDATA.id,0,Err)'
EQU STDDATA.record.writeu LIT
'FFileOperation(W,STDDATA,STDDATA.FILE,STDDATA.record,STDDATA.id,1,Err)'
EQU STDDATA.SELECTLIT
'FFileOperation(S,STDDATA,STDDATA.FILE,STDDATA.id,,0,Err)'
* Properties
EQU STDDATA.name TO STDDATA.record1
EQU STDDATA.datestart TO STDDATA.record2
EQU STDDATA.dateend TO STDDATA.record3
EQU STDDATA.value TO STDDATA.record4
Etc
The function FFileOperation will lookup the file in a table of tables as it
where and determine if it is a csv, xml, sql or u2 file ( that table also
includes the EXT, filename, SQL command etc to use for acces) and then do
the correct procedure to read/write - a chunk of code in there so i wont
include it in here, but it does mean all reads and writes go through that
one piece of code...
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Wolverton
Sent: 14 July 2011 13:41
To: 'U2 Users List'
Subject: Re: [U2] Record Locks - How long should they last for? (Opinion)
WELL - optimistic lock testing is WAY more than 2 lines of code! You have
to have a 'structure' to 'store' the original data image in, then on the
write, check that image against a current version (that you DID hard lock)
and if the same, write, if not fail. If you can do that in 2 lines of code,
you're a better programmer than I am! LOL!
But Tony's point was that you either have to 'code' for each kind of write
to have one routine work from both standard locks or optimistic locks. That
would add dozens of lines of code to each routine.
Perhaps a more interesting example might be -- what if your business model
would make it more efficient to move one of the files 'off world' to a SQL
store on another machine?? If you 'called' a subroutine to do your reads
and writes, those could actually handle that 'File A is now an SQL file
while File B is still UniData' and handle that 'migration issue' with no
changes to any business logic. When your program made a 'call' to read Key
XYZ from File A, at one time it was a 'direct read' while now it's SQL query
for that data to another machine -- the only program that changes is your
'READ' and 'WRITE' program being able to intercept and mangle the data such
that the 'business logic' program just gets the MV record structure it was
asking to retrieve.
Just sort of a nifty idea.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen
Sent: Thursday, July 14, 2011 7:28 AM
To: 'U2 Users List'
Subject: Re: [U2] Record
Re: [U2] Record Locks - How long should they last for? (Opinion)
Code:- Read rec from fil,id else rec='' rec.checksum = checksum(rec) ... logic ... * write data back Readu tmp from fil,id else tmp='' If checksum(tmp) = rec.checksum THEN Write rec on fil,id Else Release fil,id Go do whatever it is you now need to do END So maybe 3 or 4 lines -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Wolverton Sent: 14 July 2011 13:41 To: 'U2 Users List' Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) WELL - optimistic lock testing is WAY more than 2 lines of code! You have to have a 'structure' to 'store' the original data image in, then on the write, check that image against a current version (that you DID hard lock) and if the same, write, if not fail. If you can do that in 2 lines of code, you're a better programmer than I am! LOL! But Tony's point was that you either have to 'code' for each kind of write to have one routine work from both standard locks or optimistic locks. That would add dozens of lines of code to each routine. Perhaps a more interesting example might be -- what if your business model would make it more efficient to move one of the files 'off world' to a SQL store on another machine?? If you 'called' a subroutine to do your reads and writes, those could actually handle that 'File A is now an SQL file while File B is still UniData' and handle that 'migration issue' with no changes to any business logic. When your program made a 'call' to read Key XYZ from File A, at one time it was a 'direct read' while now it's SQL query for that data to another machine -- the only program that changes is your 'READ' and 'WRITE' program being able to intercept and mangle the data such that the 'business logic' program just gets the MV record structure it was asking to retrieve. Just sort of a nifty idea. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen Sent: Thursday, July 14, 2011 7:28 AM To: 'U2 Users List' Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) Because it is just 2 lines of code anyway so why bother -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 13 July 2011 23:46 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3762 - Release Date: 07/13/11 ___ 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3764 - Release Date: 07/14/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
Symeon: Man...my modified optimistic update subroutine is at least 35 lines of code; which doesn't take into account managing the checksum variable. :-( Bill - Original Message - *From:* syme...@gmail.com *To:* 'U2 Users List' u2-users@listserver.u2ug.org *Date:* 7/14/2011 5:27 AM *Subject:* Re: [U2] Record Locks - How long should they last for? (Opinion) Because it is just 2 lines of code anyway so why bother -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 13 July 2011 23:46 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3762 - Release Date: 07/13/11 ___ 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] Record Locks - How long should they last for? (Opinion)
From: Symeon Breen rec.checksum = checksum(rec) If checksum(tmp) = rec.checksum THEN Symeon, there's no doubt that coding optimistically is easy, but in addition to requiring a custom statebag you also need to manage timeouts. Wol and others have commented on some of the nuances here. Optimistic locking wouldn't magically be solved by the existence of READUO. In fact, I say easy because it's just grunt work to implement, but in reality it's a completely different coding paradigm from persistent, pessimistic coding. With a full implementation, a READUO facility would eliminate the statebag, manage timeouts, and help with the housekeeping required for a real multi-user environment. More than that, it would standardize the mechanism for handling something that right now every MV developer needs to re-invent on his/her own. Now, with functions and/or CallSubs posted at pickwiki.com, people in this community could collaborate to refine and standardize optimistic programming techniques for everyone. With my cynical outlook on such things these days, I'll summarize as I have been recently with... As if... T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
From: Tom Whitmore Personally, optimistic locking is not an ideal method for performing updates. I know that is the way many DBs work but that doesn't make it right. Uh, but that IS the way that every web-based application on the planet works. C'mon now. Arguing the way things work is what keeps MV in the Jurassic era. While it's fun to hold ground for an academic discussion, we can't successfully argue against the way everyone else does things. We simply need to adapt, or as we have been doing, go extinct. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Record Locks - How long should they last for? (Opinion)
I had started to write a perl / uv integration modules for use with perl (but could be anything else - php, ... ) whereas you could OPEN files and READ / WRITE records and manipulate dynamic arrays. Basically, I had a UV phantom (or not phantom - take your pick), which was linked to a perl listener program via FIFOs/Seqential READ/WRITEs The perl (or whatever) programs would negotiate commands via the port, which then the perl listener would pass off to the UV program. It was originally designed so a website that was not local (but had perl ability for a .cgi), could OPEN and READ/WRITE data to a UV Server. If I needed to lock a record (READU), that wasn't a problem, but I needed to come up with a time frame to allow that record to be locked for, I initially chose 15 minutes (after which the UV program would release the lock). Given the issues of web traffic, where one might pull a record, then close a browser, which unless you have some sort of AJAX routine in the webpage which can alert the server that browser is no longer open (maybe hitting an API every 5 seconds - once you go 30 seconds without the API being registered - the server can consider the browser page to be closed?) So what is the thought on how long should one keep a record lock? This doesn't have anything to do with physical programs that run from telnet or so, where the system once it senses it's disconnect would release all locks - which is not so easy to do with a web connection, and one that is connected via port commands (essentially an API in itself). George Gallen Senior Programmer/Analyst Accounting/Data Division, EDI Administrator ggal...@wyanokegroup.com ph:856.848.9005 Ext 220 The Wyanoke Group http://www.wyanokegroup.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
It would depend on what the application was on the web server. I'd think about the security issues a bank has and how long it was before their sessions timeout and require you to re-login. Then you have the consideration of how long a user might take to complete a transaction, such as dating sites profile entry. Nothing worse than getting just the right profile descriptions, hitting NEXT and finding out I didn't type fast enough for saving the page. (Just guessing about that one. Honest!) If you can break up the entry (or whatever the action) into multiple stages, the time would obviously be able to be shorter. As to what the exact amount of time would be, I'd find someone who hasn't seen your process, time them, then probably double, or even triple, the time they need to complete the task. Just some thoughts that come to mind. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen Sent: Wednesday, July 13, 2011 5:59 AM To: U2 Users List Subject: [U2] Record Locks - How long should they last for? (Opinion) I had started to write a perl / uv integration modules for use with perl (but could be anything else - php, ... ) whereas you could OPEN files and READ / WRITE records and manipulate dynamic arrays. Basically, I had a UV phantom (or not phantom - take your pick), which was linked to a perl listener program via FIFOs/Seqential READ/WRITEs The perl (or whatever) programs would negotiate commands via the port, which then the perl listener would pass off to the UV program. It was originally designed so a website that was not local (but had perl ability for a .cgi), could OPEN and READ/WRITE data to a UV Server. If I needed to lock a record (READU), that wasn't a problem, but I needed to come up with a time frame to allow that record to be locked for, I initially chose 15 minutes (after which the UV program would release the lock). Given the issues of web traffic, where one might pull a record, then close a browser, which unless you have some sort of AJAX routine in the webpage which can alert the server that browser is no longer open (maybe hitting an API every 5 seconds - once you go 30 seconds without the API being registered - the server can consider the browser page to be closed?) So what is the thought on how long should one keep a record lock? This doesn't have anything to do with physical programs that run from telnet or so, where the system once it senses it's disconnect would release all locks - which is not so easy to do with a web connection, and one that is connected via port commands (essentially an API in itself). George Gallen Senior Programmer/Analyst Accounting/Data Division, EDI Administrator ggal...@wyanokegroup.com ph:856.848.9005 Ext 220 The Wyanoke Group http://www.wyanokegroup.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3761 - Release Date: 07/12/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
Based on your description, you are using a pessimistic locking approach (similar to a telnet user) for a web application, so choosing a timeout would be arbitrary. Your heartbeat idea could be tied in to avoid having to manually release records. It seems like a bad idea to force a connectionless, stateless web browser to act like a connected, stateful telnet session. Why not switch to an optimistic locking approach? Checksum the original data (record) when it is passed to the browser. When returned from the browser, lock the record and checksum it again. If the checksums match proceed with the write; otherwise, send a message back to the browser allowing the user to cancel or resubmit their changes. This way, record locks should only last a few milliseconds. rex ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
-Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Rex Gozar Sent: Wednesday, July 13, 2011 1:08 PM To: U2 Users List Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) Why not switch to an optimistic locking approach? Checksum the original data (record) when it is passed to the browser. When returned from the browser, lock the record and checksum it again. If the checksums match proceed with the write; otherwise, send a message back to the browser allowing the user to cancel or resubmit their changes. This way, record locks should only last a few milliseconds. I was thinking along similar lines as well as an option, instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. rex ___ 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] Record Locks - How long should they last for? (Opinion)
That sounds feasable, but depending on how your web application is used you might also have to consider the possibility of multiple web users accessing the same record. You might need some unique user id key included in the token that gets carried around by the web session. I think you would have to completely deny access to all but the first web user because you only have stale data to give them at that point. And of course there's always the possibility someone's browser might crash and cause them to lock themselves out of the application for the pre-determined READU period. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen Sent: Wednesday, July 13, 2011 10:28 AM To: U2 Users List Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Rex Gozar Sent: Wednesday, July 13, 2011 1:08 PM To: U2 Users List Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) Why not switch to an optimistic locking approach? Checksum the original data (record) when it is passed to the browser. When returned from the browser, lock the record and checksum it again. If the checksums match proceed with the write; otherwise, send a message back to the browser allowing the user to cancel or resubmit their changes. This way, record locks should only last a few milliseconds. I was thinking along similar lines as well as an option, instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. rex ___ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
We use optimistic locking with a version number in each record (in our case Cache' handles the versioning based on our specification of the files, but either versioning or checksums works). This is a solid approach for web apps instead of using pessimistic locking. --dawn On Wed, Jul 13, 2011 at 12:07 PM, Rex Gozar rgo...@gmail.com wrote: Based on your description, you are using a pessimistic locking approach (similar to a telnet user) for a web application, so choosing a timeout would be arbitrary. Your heartbeat idea could be tied in to avoid having to manually release records. It seems like a bad idea to force a connectionless, stateless web browser to act like a connected, stateful telnet session. Why not switch to an optimistic locking approach? Checksum the original data (record) when it is passed to the browser. When returned from the browser, lock the record and checksum it again. If the checksums match proceed with the write; otherwise, send a message back to the browser allowing the user to cancel or resubmit their changes. This way, record locks should only last a few milliseconds. rex ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Dawn M. Wolthuis Take and give some delight today ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
Tony, wouldn't READL in Unidata count? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
Kevin: According to the BASIC manual: Description The UniBasic MATREADL command assigns the values found in successive attributes of a record to corresponding elements of a dimensioned array. MATREADL checks for locks and will not read a record locked with an exclusive (U) lock. If the record is available, MATREADL reads and sets a shared (L) lock on it. Note: UniBasic locks are advisory only. They prevent access by other lock-checking commands only. For more information about UniBasic locks, see Developing UniBasic Applications. I think this is different than the optimistic locking Tony was talking about, and another thread was discussing. This is where one reads a record over the web, makes changes, then sends the data back to be updated. During the update, one reads locks the record, compares this record with the originally read record that was sent over the web , and aborts if the original record was changed during this time period. It would be nice if this could be done via a statement in BASIC. We add to this by accepting any changes to data we didn't change on the web side. I think that's what Tony was talking about, but I could be wrong. Bill - Original Message - *From:* precisonl...@gmail.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 7/13/2011 4:35 PM *Subject:* Re: [U2] Record Locks - How long should they last for? (Opinion) Tony, wouldn't READL in Unidata count? ___ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
Ah... thank you for clarifying - and gently at that! ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record Locks - How long should they last for? (Opinion)
why haven't the MV DBMS vendors created a READUO Possibly in part because of the need to then have resolution mechanism for when 2 processes change the same data (assuming of course that the data wasn't, say, an accumulation total) -- what interface would you use telnet will not work nicely with the web app described, nor with someone using, say UOJ Still, extend a bit, and it could throw an error with the differences to be handled by whatever application layer -- but of course the real kicker in all of this is, and always has been, the wealth of legacy code that WOULDN'T use the new mechanism without a major rewrite and if you get to THAT point, refer to why U2 thread :-( Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, 14 July 2011 8:46 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record Locks - How long should they last for? (Opinion) After all of these years, why o why haven't the MV DBMS vendors created a READUO mechanism which allows us to optimistically lock records in exactly the way that George, Rex, and a hundred other app developers have indicated over the last 15 years? Design tip: For all new development, abstract your file IO and all OS access into separate functions, Includes, and/or subroutines, away from the business code. This way you can change your datastore interaction without messing with your application logic, and you can re-use the routines for a lot of different work. The application needs to be aware of whether you're moving forward with a pessimistic or optimistic lock, but your app code shouldn't have to manage those mechanisms. T From: George Gallen ... instead of the checksum token method, I was going to write the record to a holding file with an ID that was a combination of file/record/transaction token And do a comparison using the saved item to see if record changed, but only if the record lock had expired - I still wanted to keep the locks since the system could be used by local users as well, which is easier using the READU locally to test for locking. ___ 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
