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
