Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!bloom-beacon!gatech!ncsuvx!mcnc!rti!tijc02!pjs269
From: pjs269@tijc02.UUCP (Paul Schmidt        )
Newsgroups: comp.databases
Subject: Distributed Database Locking
Message-ID: <207@tijc02.UUCP>
Date: 14 Mar 88 15:29:36 GMT
Organization: Texas Instr., Johnson City TN
Lines: 70

Distributed Database Management Systems and locking

I am doing research into distributed databases for my Master's Thesis
and I have a few comments and questions.

First I feel there are two methods for locking distributed databases.
One is to lock all resources before a transaction is started and the
other is to lock resources as they are needed.  Locking all resources
first gaurantees deadlock prevention, but may lock resources that are
not needed, and keep them locked for longer than they are needed.  By
locking resources when they are needed, one can avoid unnecessary locks
but a deadlock detection scheme would have to be used.  (Resource, in
my view, is any peice of data; a relation, a tuple, or an attribute in
a tuple.)

Let me go over a few of the pros and cons of each method.
	
Locking of all resources at the beginning of the transaction has the
following advantages:  ease of implementation and deadlock prevention.
This will be easier to implement since a deadlock detection algorithm
and transaction rollback scheme does not have to be implemented.
Deadlock is prevented in this scheme.

Locking of all resources at the beginning of each trasaction has the
following disadvantages:  possibility of wasted processing time at a
node, all resources must be locked on transaction invocation, and
unneeded resources may be locked.  Wasted processing time can occur
when a node has locked a resource but is not currently using it.
Not all transactions can be clearly defined when they are invoked so
forcing all resources to be locked at invocation will make some applications
difficult, if not impossible, or may force the locking of unneeded 
resources.

Locking of resources as needed has the following advantages:  Resources
are locked only when being used, and the total transaction does not need to
be known at the start of the transaction.   Since resources are only locked
when they are being used, processing time will not be lost when another
process is waiting on that resource.

Locking of resources as needed has the following disadvantages:  A deadlock
detection and recovery scheme must be implemented, time may be wasted
when a possible deadlock is recovered from, and it is much harder to
implement.

It appears that the first proposal is the simplest way of implementing
a Distributed DBMS but it has some serious drawbacks.  Specifically, it
can hurt the performance of a distributed system by having unneeded
resources locked.  But the second proposal will have problems if deadlock
is detected often and the recovery takes longer than the time we saved.

Questions:

Are there other methods?

What are the distributed deadlock detection schemes?

How can one tell when one method is better than the other?

How do crash recovery and deadlock detection rollback relate?  Are most of
the recovery problems already solved by crash recovery?

Any references and comments on this subject would help further my 
research greatly.


	Paul Schmidt - East Tennessee State University
	502 West Pine Street
	Johnson City, TN 37604

	EMAIL: mcnc!tijc02!pjs269