Path: utzoo!mnetor!uunet!husc6!ut-sally!im4u!speegle
From: speegle@im4u.UUCP (Greg Speegle)
Newsgroups: comp.databases
Subject: Re: Distributed Database Locking
Message-ID: <2608@im4u.UUCP>
Date: 17 Mar 88 03:49:10 GMT
References: <207@tijc02.UUCP>
Reply-To: speegle@im4u.UUCP (Greg Speegle)
Organization: U. Texas CS Dept., Austin, Texas
Lines: 67

In article <207@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt        ) writes:
>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.

Non-locking mechanisms also exist, such as distributed timestamps.

>Locking of all resources at the beginning of the transaction has the
>following advantages:  ease of implementation and deadlock prevention.
>... transaction rollback scheme does not have to be implemented.

Transaction rollback must still be implemented in case of user aborts.
One of the big advantages (or disadvantages of the lock as needed approach)
is you don't have to check for non-existant deadlocks. Most deadlock 
detection schemes check whenever a deadlock MIGHT exist, thereby checking
when one doesn't exist.
 
>Questions:
>
>Are there other methods?

See above.

>What are the distributed deadlock detection schemes?

There are so many distributed deadlock detection schemes out in the world
that to even try to list them all would take forever. Check Sigmod and 
VLDB for the last 5 years (maybe more!) and you'll find plenty. Be careful,
though, as incorrect algorithms are sometimes published.

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

This is an area of current research and depends on what you mean by better.
Some are better in terms of messages sent, others are better in terms of 
time before a deadlock is detected. You'll have to establish your own 
criteria for what is better. Another idea would be to implement different
algorithms and see which worked better. Does anyone know if this has
been tried? I would think it has, but I don't know.

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

A deadlock detection rollback is a system determined abort of a transaction.
Any changes to the database must be "undone" by the system. However, some
methods of crash recovery are based on the concept of "redo"-ing the 
transaction, while others are based on an "undo" scheme. So the answer
is maybe, depending on the crash recovery algorithm used.

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

The best reference is the book by Ceri and Pelagatti(sp?) which is called
"Distributed Databases" or something very similar. They cover all of the
basics of concurrency, recovery and design of distributed databases.

>	Paul Schmidt - East Tennessee State University
>	502 West Pine Street
>	Johnson City, TN 37604
>
>	EMAIL: mcnc!tijc02!pjs269

Greg Speegle
-- 
{seismo,ihnp4,pyramid}!ut-sally!speegle		speegle@sally.utexas.edu