home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!uwm.edu!linac!sunova!higgs.ssc.gov!jbaron
- From: jbaron@higgs.ssc.gov (Jeff Baron)
- Newsgroups: comp.databases.sybase
- Subject: RE: locking flame
- Message-ID: <1992Nov9.185829.19395@sunova.ssc.gov>
- Date: 9 Nov 92 18:58:29 GMT
- Article-I.D.: sunova.1992Nov9.185829.19395
- References: <BxGJCs.4Lx@csfb1.fir.fbc.com>
- Sender: usenet@sunova.ssc.gov (News Admin)
- Reply-To: jbaron@higgs.ssc.gov (Jeff Baron)
- Organization: Superconducting Super Collider Lab
- Lines: 31
- Nntp-Posting-Host: higgs.ssc.gov
-
- Lawrence Hall writes:
-
- - create table x ( a char(10), b char(10), c char(10))
- -
- - Populate with 5000 rows - the unique key being a + b, but no index yet.
- -
- - select * from x holdlock where a = '1' and b = '2'
- - This takes an exclusive table lock even though we only need one page out
- - of 75.
-
- This locks all of the table in order to prevent another process
- from inserting data into the table that might somehow change the
- results of this query while the transaction that this query is embedded
- in is still active.
-
- - create unique clustered index z on x(a,b)
- -
- - select * from x holdlock where a = '1' and b = '2'
- - With the unique index, this locks 2 page
-
- You should be able to see that now, Sybase can prevent someone from
- inserting an 'a=1, b=2' record by locking only the pages in the table
- where that record would be located, since it is *known* where
- that record would be. (I wonder, in fact, if the 2nd, or even both,
- pages are higher-in-the-index-tree index pages of some sort, presumably the
- ones that sit "above" the record(s) in question. The net result would
- be identical.)
-
- --
- Jeff Baron
- jbaron@gauss.ssc.gov
-