Hi Stuart, you are talking about READU not READL. Of course it is dangerous to allow a user to read a record without locking it if that user can then write that record back. But READL will not allow any user to WRITE, not even the holder of the lock unless all locks have been released. OTOH it is contrary to your statement quite useful not to lock "everything" during a process when no update will occur. Why lock the customer master record for instance if it is only read to display the name and address on a screen? And even your example with the exchange rate doesn't really make sense. If you want to make sure the exchange rate doesn't change then you read it once and assign the value to a variable. Especially on large systems locking the exchange rate record of a popular currency every time somebody reads it can cause serious problems. And no, I don't think this would be a good application for READL, since you only can update the exchange rate once all locks have been released. Imagine you have 1000 or more users and the poor person trying to update exchange rates has to wait until everybody who uses a process that uses this rate to release their locks.
Mecki On 01/09/2010 07:25, Boydell, Stuart wrote: > 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: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble > Sent: Tuesday, August 31, 2010 7:07 PM > To: 'u2-users@listserver.u2ug.org' > 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: u2-users-boun...@listserver.u2ug.org > <u2-users-boun...@listserver.u2ug.org> > To: U2 Users List <u2-users@listserver.u2ug.org> > 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 > 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
