Re: Holding Locks?

Posted in 1991

Walt Hultgren {rmy} — Mon, 28 Oct 91 15:20:36 -0500 — source: Informix-list mailing list archive (1991-1998)

Path: emory!swrinde!sdd.hp.com!hplabs!nsc!pyramid!infmx!news From: cortesi@informix.com (David Cortesi) Newsgroups: comp.databases.informix Message-ID: <1991Oct18.161916.8475@informix.com> Date: 18 Oct 91 16:19:16 GMT References: <1991Oct18.015545.29600@henson.cc.wwu.edu> Sender: news@informix.com (Usenet News) Reply-To: cortesi@informix.com Organization: Informix Software, Inc. In article <1991Oct18.015545.29600@henson.cc.wwu.edu>, n8420101@henson.cc.wwu.edu (Chris A. Hopen) writes: > > I am using Infomix OnLine 4.0 and ESQL/C under DG/UX 4.31 > and have a unique problem. I have a group of 4 tables that I > want to lock and keep locked until I am done with all the processing > I need to perform. The first part (i.e Locking the tables) is quite > simple, but my question is how do I keep them locked when I am accessing > a database that uses logging? In (I believe) all SQL databases when > you "commit work" all row-level and table-level locks are released... Quite true. The only lock that survives a COMMIT/ROLLBACK is the database lock from using DATABASE <dbname> EXCLUSIVE. You could consider using that. Another possibility, if all the programs involved are under your control, is simply to have a table in the database that represents a one-row semaphore. Fetch that one row for update; if it doesn't read "BUSY" then update it to read "BUSY"; commit work; and proceed without table locks. If it does read "BUSY" then do -- whatever your programs have to do to avoid contending with each other. > If anyone has run into this problem or one similar, PLEASE let me know > asap before I go off writing some unnessary locking functions on top > of the standard UNIX file system .... The very little that you say about your problem is enough to raise red flags, ring alarm bells, sound sirens etc. in my mind. You make me very dubious about the design you are attempting. Please post a more complete description of what you are doing and why this unusual locking is needed. Maybe other readers can suggest an alternate design that avoids these problems.