Row locks and CGI (was: Re: row locks and ODBC)

On 25 Mar 1997, Ofer Inbar wrote: > We'd like to have some sort of locking to prevent a local user from > modifying a row that the CGI program has read and plans to modify and > write back in. I'm not very familiar with the relvant Informix words > & concepts, but are "row locks" what I want to use? Since CGI scripts are inherently stateless, you probably want to roll your own locking solution here -- ie: don't rely on Informix to do it for you, but handle it programattically. This assumes that either you can trust your programmers, or that you wrap all SQL in functions that take care of it for you (may be the better route). > The developers of the ODBC application (I am not one of them, I'm just > supporting them and the database) would like to know: > - How can their programs lock the appropriate rows when they read > the data, and unlock them when they write the new data in? > - What happens when something has already locked that row? Once a process that has an Informix level row lock (assuming online engine, its been a while since I've messed with SE) dies, that lock is released. Not what you want for stateless processing. > I would additionally like to know: > - What's a good way to deal with the fact that occasionally, a CGI > instance will read data and lock it, but die before it completes > its work? Can locks "time out"? Some form of lock-storage table containing row, datetime locked, and/or datetime for lock to expire, with a daemon killing off expired rows (or leave them for an audit trail and select on valid datetimes whatever is deemed appropriate) would be one way to deal with this problem. I don't know if it's the best way, but its one way. Note that this is going to be a very heavily hit table, take that into consideration. -Richard Stanford Dallas Systems Corporation richards@herald.net richards@dalsys.com My thoughts, not employer's, yadda yadda yadda. YKWIM.