> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bob Woodward > Sent: Friday, February 17, 2006 12:35 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Using keys for record locking with time > expirations... > > > If you're going to use the system you've laid out for locking, you're > going to have to be sure to code for the situation where the > web request > comes after your timed lock release has happened.
It would need to return a lock expired error, and the originating perl script (on the web page), would have to be programmed on what to do then. > > To institute the timed portion, you'll probably have to have a phantom > running that scan's your lock keys to see if time has > expired. The initial application I had envisioned would be running with "soft" locks where as the lock would be maintained only by the phantom, not by the OS so I wouldn't require a second phantom to cleanse the locks. Just if a read or write comes in without the proper key and the existing lock is expired, it would just go ahead and do the request. The amount of read/writes per 24 hour that I'm talking about are probably in the range of 100-200, so I'm not talking about a large scale implementation. but, if I were to up the scale, I most likely would need to make the locks "hard" locks and add in more support phantoms. But for now, I just want to get it operational, then I can build on it. I'd also > probably put the expire time in the lock key so you don't have to do a > data record read, just a readnext. This, of course, requires your web > connection to be able to regen the lock key with the expire time. > Either the phantom or the lock request is going to have to do > a select, since the amount of locks will not be very large, I intended on maintaining the lock list and key list within a dynamic array and use of LOCATE. > I'm sure, so you'll have to decide which is going to be the least > expensive to performance from the user's perspective. > > Without knowing more of what your application requirements are, I'm > assuming a read/re-read/compare-to-original method is unacceptable. I > think they call this Optimistic Locking. I like the of idea of read/re-read/compare to see if anything else has changed the record . I may consider using that if a write comes in with an expired lock, and nothing has changed, to go ahead and do the write otherwise return an error code. > > HTH's. thanks > > BobW ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
