redbookcover.gif (13955 bytes) Readings in Database Systems, 3rd Edition

Stonebraker & Hellerstein, eds.

Distributed DBMS: Overview & Concurrency Control

Goal: a small-scale (dozens of sites) distributed DBMS

  1. Location transparency: users don’t know where the data is
  2. Performance transparency: performance independent of submission site
  3. Copy transparency: objects can be copied, and copies are maintained automatically. Critical for availability
  4. Transaction transparency: looks like single-site xacts
  5. Fragment "transparency": tables can be fragmented to different sites
  6. Schema change transparency: schema updates at a single site affect global schema
  7. Local DBMS transparency: shouldn’t matter what DBMS is running at each site (ha!)


Nobody provides all of this (#7 & #3 are still major research field)

IBM Almaden’s R* was the most "real" DDBMS prototype.

  • VTAM/CICS provided communication
  • Good optimizer, concurrency control


  • SDD-1: done at CCA, never really ran. PDP-10’s on Arpanet. Strange design decisions based on unreasonably slow network.
  • Distributed INGRES: UCB, also never ran. Lack of UNIX networking software (pre TCP/IP!).
  • Commercial vendors beginning to provide this functionality

The R* Distributed DBMS


  • location transparency
  • local privacy & control
  • local performance on local queries
  • no central dependencies: site autonomy
    • no central catalogs
    • no central scheduler
    • no central deadlock detector

Tables can be

  • dispersed
  • replicated
  • partitioned:
    • horizontal partitioning (by predicate)
    • vertical partitioning (but a key at each partition)
  • snapshots

Table names: user_name@user_site.object_name@birth_site

Catalogs store info on local objects, and objects born locally (along with pointers to current sites)

Remote catalog info is cached as hints:

    • invalid cache entries are detected easily and updated
    • catalog entries have version numbers

a catalog entry for a table:

    • System-Wide Name
    • type info
    • access paths
    • view definition (if it’s a view)
    • optimizer stats

To find a catalog entry:

    1. check local catalog & cache
    2. check birth site
    3. check the place the birth site points to

An overview of Distributed CC:

Every transaction gets an xactno: site_name.time (or SN)

deadlocks: shoot the youngest, largest-numbered xact

Commit Protocol – you can’t just decide to commit:

    • some site may not be able to
    • you can’t distingush inability from slowness!

Two Phase Commit (2PC):

    1. coordinator says to participants: want to commit? (N-1 messages)
    2. Participants all vote yea/nay (N-1 messages)
    3. coordinator tells everyone to commit/abort (N-1 messages)
    4. participants acknowledge message (N-1 messages)

This does the right thing, but it’s pretty costly. Next paper improves this.

Distributed Deadlock Detection:

  • find and resolve local deadlocks
  • pass your waits-for graph around to detect global deadlocks
  • next paper does this more efficiently

1998, Joseph M. Hellerstein.  Last modified 08/19/98.
Feedback welcomed.