Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site phri.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!timeinc!phri!roy From: roy@phri.UUCP (Roy Smith) Newsgroups: net.database Subject: Re: UNIX + database (long quick overview) [plus flock(2) question] Message-ID: <423@phri.UUCP> Date: Mon, 26-Aug-85 22:27:57 EDT Article-I.D.: phri.423 Posted: Mon Aug 26 22:27:57 1985 Date-Received: Fri, 30-Aug-85 07:23:46 EDT References: <164@3comvax.UUCP> <10185@ucbvax.ARPA> Distribution: net Organization: Public Health Research Inst. (NY, NY) Lines: 45 > From: Jeff Anton, Ingres Group > > A DBMS would be well off with three (3) levels of locks [...] shared, > update, and exclusive. [...] If you think you might have to change some > data in a file you get an update lock. [...] If you do have to change > the data you raise the lock to exclusive and wait until all the shared > locks go away. Know what else goes away? Deadlock. I'm not sure I follow. I don't see how the update lock is anything more than a hint that you might want an exclusive lock later. Like all hints (vadvise for example), this may improve efficiency, but I don't see how it really changes anything in the end. In particular, how does this eliminate deadlocks (and why doesn't the 2-stage 4.2 flock)? Since we're on the subject, there's something I don't understand about the 4.2 flock(2) call. As I understand it, having a shared lock guarantees that the file can't change beneath you. But when you update your shared lock to an exclusive one, "this results in the previous lock being released and the new lock applied (POSSIBLY AFTER OTHER PROCESSES HAVE GAINED AND RELEASED THE LOCK)" [my emphasis]. This doesn't make sense; you poke around in the data base to figure out what you want to do and then, just before you are ready to write your changes, you give somebody else a chance to write theirs? Doesn't that mean that you then have to go back and re-compute your whole update? I can see how *not* giving others a shot when you upgrade a lock might lead to deadlocks (which would answer my previous question nicely, thank you). As I read the manual, though, it just doesn't make sense. Can somebody tell me what I'm missing (if anything)? > [talking about reliability and limitations of the file system] > But for the banks and the purests, we're working on what may be a way > around the problems. I'm not sure enough right now to publicize yet. If there are problems with the file system, why can't you just open up a raw disk and implement your own like was done for testing the 4.2 F.S. under a 4.1 kernel? I don't see any way to get around the write-behind strategy in the block I/O system, but at least you can make multi-volume files if you want. You could even implement shadow pages and volumes (to keep "the banks and the purests" happy) in the user-level file system routines. Cpu cycles *are* cheaper than HSC-50's, aren't they? :-) -- Roy Smith System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016