On Thu, Jun 15, 2000 at 12:45:52AM +0200, Jan Wieck wrote:
> Believe it or not, but holding pure DB locks over
> "interaction" in an interactive application isn't what you
> really want! The user might go for coffee, and such long time
> locks are not what the locking mechanism of databases is
> intended for - so it's not optimized for this kind of abuse!
Allow me to echo the above sentiment. Our library automation system is
built on a PICK back end (UniVerse), and the implementation locks any record
that is in current use. A good thing, that, in so far as you don't want,
say, two people writing to the same patron record at the same time. Problem
is, patrons are frequently checking books out while someone else is checking
in the items the patron had out before. Kablooey.
What's supposed to happen, of course, is that the ckeck-in or check-out
clerk gets a message, "patron file is locked -- wait or quit?" In practice,
there are too many cases where lock contention is not handled properly, and
both terminals get locked up. This is often a pain to resolve; I spend
quite a bit of time just trying to figure out where the lock is coming from.
And this doesn't even begin to touch the times where a staff member was
helping a patron look at his/her holds (or whatever), and then just left the
session logged in to that person's record (which is a problem of bad user
behaviour, yes, but knowing that doesn't help when you're trying to break
someone's 20 year bad habit).
Use transactions. Much better than locking.
--
Andrew Sullivan Computer Services
<sullivana@bpl.on.ca> Burlington Public Library
+1 905 639 3611 x158 2331 New Street
Burlington, Ontario, Canada L7R 1J4