Hi Tom, READL is useful. Normatively, DBMS theory says you should lock *everything* during a process to guarantee that other processes aren't making changes to the db underneath your process. In practice, I've seen a lot of code which doesn't do this. Most of these systems must simply get away with it through sheer dumb luck.
Looking at the standard read mechanism; Consider two sessions (pid 101 & 102) running on a U2 database both READ a customer record, X at the same time (without locking). Both processes update a comments field; both processes write X back to file. (101 reads X, 102 reads X, 101 changes X, 102 changes X, 101 writes X, 102 writes X.) In the scenario above the comments added by 101 are lost because 102 overwrites the changes made by 101. This is an obvious problem with concurrent use of a DB. To fix this you use pessimistic locking and an update lock, READU. This will ensure that if 101 and 102 both try to READU the record, the second process will fail (hopefully gracefully). All good. Now what if the user also needs to read (and not update) a shared parameter item? For example, a spot currency conversion rate. Consider if your process (101) reads, without locking, a rate, while another (102) updates it; you do some processing with the old rate, writes some files, calls a subroutine that re-reads the rate that has just been written by 102 and then does some calculations and writes to some more files - the db could now be inconsistent with figures calculated against both the old and new rate. (101 reads rate, 102 reads rate, 102 changes rate, 102 writes rate, 101 calculates partly based on old rate and new rate). If you (101) were to use READU it would stop other processes from updating the rate while you were doing your calculation but also any other processes which needed to just read the rate record (because they would also be using READU). That could get annoying for users! This is where READL is useful, as it allows a shared lock to be set - ensuring that the record can't change while your (or any other) process has a shared lock on it but allowing the record to be read by any number of processes. The updating process would have to wait till it could get a READU before changing the data. If you use BEGIN/END TRANSACTION in a program then within the transaction boundary best practice locking is enforced. Transactions have to guarantee consistency (ACID), so that you can roll back a set of updates and leave the database in exactly the state it was in at the beginning of the transaction. In this case using READU and READL are mandatory. Hope that helps. Cheers, Stuart -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tom Whitmore Sent: Wednesday, 1 September 2010 11:51 To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Hi, The READL is one verb that causes a lot of confusion, and I have not found a use for it. READU prevents another person to lock the record, but regular READs continue to work without a problem. READL permits multiple READL or READ but no READUs/WRITES are permitted. You cannot update with a READL, because WRITES require a record lock. As I said, I don't understand why anyone would use it. Tom RATEX Business Solutions. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan Goble Sent: Tuesday, August 31, 2010 7:07 PM To: '[email protected]' Subject: Re: [U2] [UV] Shared Record Locks When you have data you want to update, but do not want to prevent people from viewing the rest of the data. I.E. Updating patient information for the next insurance enrollment period, and still letting customer service reps access the data to help customers. HTH -Dan ----- Original Message ----- From: [email protected] <[email protected]> To: U2 Users List <[email protected]> Sent: Tue Aug 31 15:34:51 2010 Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to "share" their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com <http://www.zirmed.com/> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
