ccrms@ucdavis.UUCP (Michael Shulman) (09/06/85)
I think I understand all of the problems necessitating
updates by only one user at a time. But what I don't
understand are the different ways that these locks are
implemented. What happens to the index file(s) in use
if fields or records are locked? Is it necessary to
lock the index also? And doesn't locking the index lock
the entire file?
Also, can you use multiple indices with B-trees or ISAM files?
Thanks...
--
Michael Shulman
Microcomputer Consultant
University of Calif, Davis
... ucbvax!ucdavis!deneb!ccrms
(916)752-1667 8-12, 1-5 Pacific Time
{Disclaimer: the opinions expressed here are mine alone, and may
or may not represent those of my employer or
the price of tea in China.}dimare@ucla-cs.UUCP (09/12/85)
ccrms@ucbvax (Michael Shulman) asks: > I think I understand all of the problems necessitating > updates by only one user at a time. But what I don't > understand are the different ways that these locks are > implemented. What happens to the index file(s) in use > if fields or records are locked? Is it necessary to > lock the index also? And doesn't locking the index lock > the entire file? You have to lock both, as otherwise you could not guarantee that the index and the file are consistent. Nothing is ever for free: somebody's got to lock both the file and the index. If your access method or data base system doesn't do it for you, then you better do it. But usually systems are smart enough to do this. I don't know, though, how micro implementations work (this might be one of the reasons why we don't yet have a lot of lan-dbms's). There are many other ways to do 'locking'. You can find a good survey in: %A Walter H. Kohler %T A Survey of Techniques for Synchronization and Recovery in Decentralized Computer Systems %J ACM Computing Surveys %V 13 %N 2 %D June 1981 %P More than 26 pages > > Also, can you use multiple indices with B-trees or ISAM files? B-trees are, by the most, and indexing method, although you could also store the whole file as a B-tree. This is not what Vsam does, by the way. I don't really know what you mean by multiple indices with B-trees. Let me guess: If what you want is to have several indices, then you need one B-tree for each one of them. Or you could have some of them be B-tree and the others be Isam or use any other indexing technique. Can the SAME B-tree be 2 indices. No, in most cases, because the ordering of the entries in the B-tree for one index could be in conflict with the ordering of the other index. If you had a file like this: FILE(Zip,Street,Name), then a B-tree index on [Zip,Street] would also be an index on [Zip], but any of these 2 would surely conflict with [Name]. You can find a good description of B-trees in %A Douglas Comer %T The Ubiquitious B-Tree %J ACM Computing Surveys %V 11 %N 2 %D June 1979 %P 121-137 %O (Also letter from 'Surveyors' Forum, Computing Surveys, 11,4, December 1979) > > Thanks... > Sure. Adolfo /// Disclaimer: If I'm wrong THOUGH! If I'm not, YOU take the credit!!!
hokey@plus5.UUCP (Hokey) (09/18/85)
It is not always necessary to lock both the data file and the index file. If one writes *consistent* software, it is only necessary to lock the index file. File locks should be *much* faster than record locks. It is not always true that one wishes to record-lock an m-tree (including B-tree) index, because the overhead associated with log m (n) can be much greater than simply locking the entire index. Timings (tradeoffs) change based on availability of shared/promotable/exclusive locks, or the availability of a single database server (which can also act as a cache). -- Hokey ..ihnp4!plus5!hokey 314-725-9492