Introduction Background

Introduction

• Introduction

• Background

• Distributed DBMS Architecture

• Distributed Database Design

• Distributed Query Processing

• Distributed Transaction Management

• Transaction Concepts and Models
• Distributed Concurrency Control
• Distributed Reliability

• Building Distributed Database Systems (RAID)

• Mobile Database Systems

• Privacy, Trust, and Authentication

• Peer to Peer Systems

D. Skeen and M Stonebraker, A Formal Model of Crash Recovery in a Distributed System, IEEE Trans. Software Eng. 9(3): 219-228, 1983.

• D. Skeen and M Stonebraker, A Formal Model of Crash Recovery in a Distributed System, IEEE Trans. Software Eng. 9(3): 219-228, 1983.

• D. Skeen, A Decentralized Termination Protocol, IEEE Symposium on Reliability in Distributed Software and Database Systems, July 1981.

• D. Skeen, Nonblocking commit protocols, ACM SIGMOD, 1981.

Message sent by an operational site

• Message sent by an operational site

• abort – If trans. state is abort

• (If in abort)

• committable – If trans. state is committable

• (If in p or c)

• non-committable – If trans. state is neither committable nor abort

• (If in initial or wait)

• If at least one committable message is

• received, then commit the transaction,

• else abort it.

Recovery Protocols:

• Recovery Protocols:

• Protocols at failed site to complete all transactions outstanding at the time of failure

• Classes of failures:

• Site failure
• Lost messages
• Network partitioning
• Byzantine failures

• Effects of failures:

• Inconsistent database
• Transaction processing is blocked
• Failed component unavailable

• Failure of j  recover to commit

• Failure of any other site  recover to abort

Timeout in INITIAL

• Timeout in INITIAL

• Who cares

• Timeout in WAIT

• Unilaterally abort

• Timeout in PRECOMMIT

• Participants may not be in PRE-COMMIT, but at least in READY
• Move all the participants to PRECOMMIT state
• Terminate by globally committing

Timeout in ABORT or COMMIT

• Timeout in ABORT or COMMIT

• Just ignore and treat the transaction as completed
• participants are either in PRECOMMIT or READY state and can follow their termination protocols

Timeout in INITIAL

• Timeout in INITIAL

• Coordinator must have failed in INITIAL state
• Unilaterally abort

• Timeout in READY

• Voted to commit, but does not know the coordinator's decision
• Elect a new coordinator and terminate using a special protocol

• Timeout in PRECOMMIT

• Handle it the same as timeout in READY state

New coordinator can be in one of four states: WAIT, PRECOMMIT, COMMIT, ABORT

• New coordinator can be in one of four states: WAIT, PRECOMMIT, COMMIT, ABORT

• Coordinator sends its state to all of the participants asking them to assume its state.
• Participants “back-up” and reply with appriate messages, except those in ABORT and COMMIT states. Those in these states respond with “Ack” but stay in their states.
• Coordinator guides the participants towards termination:
• If the new coordinator is in the WAIT state, participants can be in INITIAL, READY, ABORT or PRECOMMIT states. New coordinator globally aborts the transaction.
• If the new coordinator is in the PRECOMMIT state, the participants can be in READY, PRECOMMIT or COMMIT states. The new coordinator will globally commit the transaction.
• If the new coordinator is in the ABORT or COMMIT states, at the end of the first phase, the participants will have moved to that state as well.

Failure in INITIAL

• Failure in INITIAL

• start commit process upon recovery

• Failure in WAIT

• the participants may have elected a new coordinator and terminated the transaction
• the new coordinator could be in WAIT or ABORT states  transaction aborted
• ask around for the fate of the transaction

• Failure in PRECOMMIT

• ask around for the fate of the transaction

Failure in COMMIT or ABORT

• Failure in COMMIT or ABORT

• Nothing special if all the acknowledgements have been received; otherwise the termination protocol is involved

Failure in INITIAL

• Failure in INITIAL

• unilaterally abort upon recovery

• Failure in READY

• the coordinator has been informed about the local decision
• upon recovery, ask around

• Failure in PRECOMMIT

• ask around to determine how the other participants have terminated the transaction

• Failure in COMMIT or ABORT

• no need to do anything