Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!udel!burdvax!sdcrdcf!csun!polyslo!lchirica
From: lchirica@polyslo.UUCP (Laurian Chirica)
Newsgroups: comp.databases
Subject: Re: Distributed Database Locking
Message-ID: <1633@polyslo.UUCP>
Date: 21 Mar 88 05:19:42 GMT
References: <207@tijc02.UUCP> <2465@geac.UUCP>
Reply-To: lchirica@polyslo.UUCP (Laurian Chirica)
Organization: Cal Poly State University -- San Luis Obispo
Lines: 47

In article <2465@geac.UUCP> john@geac.UUCP (John Henshaw) writes:
>
>In article <207@tijc02.UUCP>, pjs269@tijc02.UUCP (Paul Schmidt) writes:
>> First I feel there are two methods for locking distributed databases.
>> [much text deleted]
>
>I'll confine most of my comments to LOCKING strategies. There are of course,
> [Much more good stuff deleted]

>You write:
>>                                                                    By
>> locking resources when they are needed, one can avoid unnecessary locks
>> but a deadlock detection scheme would have to be used.
>
>Could you please explain what is meant by an "unnecessary lock"? I
>imagine that you really meant to address the *timely* initiation of
>locks so that objects (resources) are locked for as short a period as
>possible. Otherwise, I will disagree: "If ya gotta lock it, ya gotta
>lock it...", hence all locks *are* necessary.

I am sure Paul can answer the question for himself but I volunteer
the following explanation: What if the set of objects to be locked depends 
on some logical condition, say "if condition A then lock set X else lock
set Y."  Locking all resources at the beginning of a transaction require
that we lock both sets X and Y.

> [A lot more good stuff deleted]

I fully agree with all the rest of your article, John.  

One more note, Jim Gray of Tandem (ex-IBM'er of IMS, System R fame and
Transaction Management guru) wrote  a paper sometime ago exposing the
idea of deadlock prevention as a "straw man."  If I remember correctly,
he had analyzed some transaction logs from IBM installations which showed
that the probability of deadlock was so small that it was not worth
the expense of preventing deadlock.  He, essentially said that we are
better off (from a performance standpoint) to let it happen, and rollback
one of the transactios involved in the deadlock.  As you pointed out John,
the rollback is needed anyway for recovery purposes.

-- Laurian

-- 
Laurian M. Chirica  (lchirica@polyslo.UUCP)
Computer Science Department
California Polytechnic State University (CAL POLY)
San Luis Obispo, CA 93407 - (805) 756-1332