[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
    Search the FAQ Archives

Part1 - Part2 - Part3 - Single Page

Top Document: Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Previous Document: [1.5.1] Data consistency
Next Document: [1.5.1.2] Relaxing consistency


[1.5.1.1] Strictly consistent systems


From: Distributed systems

Older, strictly consistent systems tend to enforce a single writer,
multiple reader model, where at any time data will be held either at a
single node (which may have write access) or several nodes (none of
which may have write access).

Given this model, we must be able to locate a copy of our data when it
is not resident.  The method most frequently used is to assign an
`owner' to each item of data, where the owner has either the only
writeable copy of the data, or one of the read-only copies.  Ownership
may remain fixed throughout the life of a datum, or it may change
dynamically.  In the latter case, the problem arises of locating the
owner.  A database of locations may be maintained by centralised
managers, or ownership information can be distributed among nodes of
the system [Li and Hudak, 89].

In a strictly consistent system, we must also be able to synchronise
writes.  The two major solutions to this problem are:

- Write broadcast.  The effects of every write are broadcast to ever
  node that has a copy of the data being written; this effectively
  implements a replication algorithm.  Write broadcast is usually
  considered too expensive to be used as a general solution.

- Write invalidation.  Each node in the system holding a read-only
  copy of the data being written is sent an invalidation message.



Top Document: Comp.os.research: Frequently answered questions [3/3: l/m 13 Aug 1996]
Previous Document: [1.5.1] Data consistency
Next Document: [1.5.1.2] Relaxing consistency

Part1 - Part2 - Part3 - Single Page


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
os-faq@cse.ucsc.edu

Last Update October 22 2009 @ 05:32 AM

Some parts © 2009 Advameg, Inc.