Path: utzoo!attcan!telly!problem!compus!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.databases Subject: Re: database implementations... Message-ID: <1990Dec7.190403.14727@odi.com> Date: 7 Dec 90 19:04:03 GMT References: Reply-To: dlw@odi.com Distribution: na Organization: Object Design, Inc. Lines: 22 In-Reply-To: swfc@cs.columbia.edu's message of 6 Dec 90 00:43:42 GMT In article swfc@cs.columbia.edu (Shu-Wie F Chen) writes: 3. What is the difference between a lock and a latch? Better yet, what is a latch? (I encountered these terms in one of the ARIES (IBM/Almaden) papers.) A latch is a lower-level primitive, used by the lock manager of a transaction system, as a cheap serialization mechanism WITHIN the lock manager itself. Latches are typically lightweight and fast, and do not deal with deadlock detection or fancy modes (such as "intent" locking). They are completely internal to the database system. They can be released during a transaction without violation of strict two-phase locking, since they are not the real locks protecting the real data. They are a lower-level primitive sort of lock; real locks are built at a higher level of abstraction within the transaction manager. Simple example: you might have a DBMS running on a multiprocessor, and there might be a single latch that implements mutually exclusive access to the in-memory table of locks. So before a process can seize or release a lock, it must first acquire this latch; then it can do the lock operation, and then it must release the latch.