From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 10-FEB-1992 18:50:09.88
To:	ARISIA::EVERHART
CC:	
Subj:	Re: Record-level locking in Rdb?

From:	RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2
To:	Everhart@Arisia@MRGATE

Received:  by crdgw1.ge.com (5.57/GE 1.123)
	 id AA02001; Mon, 10 Feb 92 18:06:49 EST
Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Mon, 10 FEB 92 12:56:17 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
	id AA26031; Mon, 10 Feb 92 12:05:05 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 5 Feb 92 09:46:48 GMT
From: prowest!pan@uunet.uu.net
Organization: Professional Press, West Coast Offices, Pasadena, CA
Subject: Re: Record-level locking in Rdb?
Message-Id: <3950.298fb288@prowest.propress.com>
References: <6F48BB6C802010D4@UCDHEP.UCDAVIS.EDU>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <6F48BB6C802010D4@UCDHEP.UCDAVIS.EDU>, MIKE@UCDHEP.UCDAVIS.EDU ("Mike Hannon; UCD Physics; -752-4966", 916) writes:
> Greetings.  On one of our systems here we are running an old version of
> Rdb (V2.2-0) on an old version of VMS (V4.7A).  The guy who does database
> programming for this system tells me that this version of Rdb does not support
> record-level locking.  In other words, if a user wants to write into a given
> table (relation), the entire table is write-locked to other people, until the
> write is complete.
>
> We'd like to be able to lock individual rows of a table for writing, so that
> two or more people could write to the table at the same time, provided they
> weren't trying to write to the *same* row.
...
>
> 					- Mike

Rdb/VMS has always done Adjustable Lock Granularity.  As I recall, there has
always been row-level locking of the type you describe.

There are several reasons that you may not be seeing the behavior you desire,
however.

First, there is a type of locking that occurs on index structures.  If multiple
users are trying to update the same index structure, they may see a lock stall
or other problem.  There is an improvment to this situation by using hashed
indices in later versions of Rdb, which may be a reason to upgrade.

Second, you may well be using the wrong level of sharing for your transactions.
If you explicitly tell Rdb to write-share the tables you are updating and
read-only the ones you are not, you may have better success, depending on your
exact situation.

Third, and possibly most important, you should realize that Rdb works on whole
sets of records at a time.  For example, if your application asks Rdb to
retrieve a set of records (i.e., "INVOICES WITH CUSTOMER_NUMBER = 3123") then
it will have to lock all of those records when it retrieves them to make sure
that they are not changed behind your back.  (Recall that Rdb guarantees
degree-3 consistency.)  If this is your situation, you should see if you can
change your application to get just one record at a time by more fully
specifying the data that you want to modify.

In sum, I don't think you are seeing exactly the behavior your describe (entire
tables being locked).

Good luck.  And RTFM'ing the more recent documentation (which is better than
the 2.7 doc) wouldn't hurt a bit.

P

_________________________________________________________________________
Philip A. Naecker                Consulting Software Engineer
Internet: pan@propress.com       1010 East Union Street, Suite 101
          uunet!prowest!pan      Pasadena, CA  91106-1756
Voice:    +1 818 577 4820        FAX: +1 818 577 0073

Also:     Technology Editor, DEC Professional Magazine
          VAX Professional Magazine Review Board Member
_________________________________________________________________________