Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> why locking a path in B-tree is not necessary

why locking a path in B-tree is not necessary

From: Mikito Harakiri <nospam_at_newsranger.com>
Date: Sun, 09 Sep 2001 22:01:14 GMT
Message-ID: <KERm7.1440$%u4.1368@www.newsranger.com>


I must apologyse in advance for posting a question, the answer to which I may easily find, for example, in Gray/Reuter's book.

Transaction isolation with locking mechanism means locking the table(s) and locking indexing data structures. What minimal part of the B-tree must be locked with exclusive lock, for example? As any of the tree node could split, it is easy to see that locking the path from leaf to the root would be sufficient. Obviously, this is not a realistic B-Tree locking implementation, since the write access becomes not concurrent at all: first transaction locks root node, and the others wait for this lock to be released. On the other hand, as we need to lock nodes in advance -- before navigating the tree -- how can we know that locking the root node, for example, is not necessary in any particular case? If we make our decision upon, say, the tree cardinality, stored as a counter somewhere, then this counter becomes a bottleneck that must be locked during any transaction...

There is no question that [physical] denormalization like indexing, or creating materialized views decreases the degree of concurrency. So, even though, the individual query might speed up, the total throughput would suffice. The question is how much? Received on Sun Sep 09 2001 - 17:01:14 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US