rfalanga@numex.unm.edu (Rod Falanga) writes:
: I have looked at the FAQ about table locking, etc.  It looks to me as
: though Ingres does not have record locking abilities.  My first
: question is, is that still true?

Yes it is.  Record locking is a greatly over-rated feature though, IMO.
I am told that a great many people who use products that do support
record-locking generally decide not to use it.  It has quite a bit
of overhead.

I often find that the desire for record-level locking shows up when 
people are using a sequential-valued surrogate key on a btree, so that
all the users inserting data get vectored to the same page and lock
each other out.  If this is your situation, consider using a 
non-sequential key, or use a hash table instead of a b-tree.
(Or, if you have space to burn, pad your records so that you get only
one per page--yuck!)

: I've seen in posts something about "shared locking".  What is that?

At its simplest, a shared lock is one that doesn't exclude other 
users from taking a read-lock. There are lots of variations on the 
theme though; you really owe it to yourself to read the chapter on 
locking in the DBA guide.

: I'm most familiar with the OpenROAD documentation, but it doesn't
: seems as though they talk much about locking considerations.  What
: book(s) should we look into in order to get a thorough understanding
: of locking issues?

Good question!!!  In my experience OpenROAD is where you need to
know the most about locking.  With multiple sessions going in the same
app, and an event-driven flow of control, you will deadlock yourself
before you know it.

--Roy Hann

Ingres Q & A

To William's Home Page

© William Yuan 2000

Email William