Browse Prior Art Database

Efficient Commit Protocol for Shared Nothing Architectures using Common Log Server

IP.com Disclosure Number: IPCOM000106629D
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 74K

Publishing Venue

IBM

Related People

Bhide, A: AUTHOR

Abstract

This invention proposes an efficient commit protocol for Shared Nothing architectures which use a common log server. This is specially useful in the case of transactions which access small portions of data at a large number of nodes, thus involving all of them in the commit protocol.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Efficient Commit Protocol for Shared Nothing Architectures using Common Log Server

      This invention proposes an efficient commit protocol for Shared
Nothing architectures which use a common log server.  This is
specially useful in the case of transactions which access small
portions of data at a large number of nodes, thus involving all of
them in the commit protocol.

      Shared Nothing database machine architectures often use a
common log server to reduce the number of disk arms needed to be
devoted to the log.  Also, under some workloads for which the data is
not easily partitionable, a single transaction in these architectures
may access data at a large number of nodes.  This implies that all
these nodes must now participate in the commit protocol.  Previous
work on two-phase commit protocols was done  for distributed
databases which did not use common log servers.  We show how the use
of a common log server can reduce the message overhead of the commit
protocol.

      Method - If the standard two-phase commit were used with a
common log-server, there are three round of messages for each
transaction commit:

1.  The co-ordinator informs all participants to prepare

2.  Each participant forces all log records related to this
    transaction and a "prepared" record to the log-server.

3.  The log-server sends an acknowledgement back.

4.  The participant then informs the co-ordinator that it is
    "prepared".  If it is unable to prepare, it sends a negative
    reply to the co-ordinator.

5.  After getting positive reply from each participant, the
    co-ordinator writes a "commit" log record and then informs all
    participants of the result.  If a negative reply/no reply is
    received from even a single participant, the co-ordinator writes
    an "abort" record for this transaction to the log-server and
    sends an abort message to all participants.

      Let there be n participants and one co-ordinator.  Then  3
times n messages are exchanged between the co-ordinator and all
participants and
 2 times n  messages are exchanged between th...