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.
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. 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, 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. HTH's. BobW -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen Sent: Thursday, February 16, 2006 12:26 PM To: u2-users@listserver.u2ug.org Subject: [U2] Using keys for record locking with time expirations... I'm changing the subject line on this topic... I'd like to get some opinons on a method (not ethics). In otherwords, I don't want statements of you shouldn't do it this way or that way because of "style" reasons. If someone has a better method, I'm all ears. I'm writing an UV interface to a non-UV access, it's been described by others as writing a device driver, where UV is the device. I've setup a small (and growing), perl script that can accept "commands" via a socket connection (from a website's .cgi) Mostly right now it's just READ data and WRITE data and SELECT data I'm using a phantom with Seqential input for "commands" and sequential output for "results" each of the sequential files are in reality a FIFO file (this way once the data is used it goes into electronic heaven without the need to cleanse the files). I already have the perl<->UV interface for commands and results functional, I'm now in the process of adding in READ data, then WRITE data. My question is that I want to institute record locking. My initial thought is when a lock is requested, a "key" is created and returned. On subsequent reads if the "key" matches the "key" for that record, the record can be updated/read if the "key" doesn't match a lockerror will be returned. My "key" also has to have an expiration in seconds/minutes, for now I'm using 60 seconds, but I may make that a varible supplied with the request for a lock (something UV doesn't have....variable length lock times...THANK GOD). The reason for this is if a request to lock occurs, and an unlock never makes it (lost in iternet land) the record can eventually be reread without human intervention. 1. I'm not using sockets for the UV interface for three reasons. a. I want UV isolated from the internet b. the perl routine that interfaces does other things besides work with UV c. If I had to change from UV to another language, all the website stuff does not need to change. and I'm sure the overwhelming question is WHHHY? Mostly it will allow a website(s) to "access" a database offsite. and if the site were ever hacked, your database isn't at risk. Some might be if the .cgi is viewed but you can't look directly at the database. My main question is : does my method for doing locking make sense? any pitfalls? or better ways (given my convoluted interfacing..) I just hope this wheel this rolls and rolls straight once i re-invent it!! George ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
