JOSHUA WONG
Menu
Course contents
On this page
Lesson 45 of 59

A silent server may still be running

Separate a timeout from proof of failure and stop an old owner from making later writes.

The shop sends a request to server A and waits. After two seconds, no answer has arrived. A might have crashed. It might also be paused, overloaded, or separated from the client by a network fault.

A timeout means the client did not receive an answer within its chosen interval. It does not identify which of those causes occurred. This matters when another server takes over A’s work.

Follow the old owner after a pause

Assume a storage service accepts writes from the current owner. A has ownership number 7. It pauses for ten seconds. During the pause, the system chooses B as a replacement and gives B ownership number 8.

B writes the current inventory. Then A resumes with an old inventory update still queued. If storage accepts writes merely because A was once trusted, the old update can overwrite B’s work.

  1. A pauses with number 7

    Its silence triggers a recovery decision; it has not necessarily stopped.

  2. B establishes number 8

    The protected storage now recognizes 8 as the current ownership number.

  3. A resumes with number 7

    Storage rejects its stale write before changing any data.

The resource being protected enforces ownership. Asking the old process to stop is insufficient when it cannot hear the request.

The monotonically increasing ownership number is often called a fencing token or an epoch. Its value is useful only if a trusted authority issues it and the resource checks it atomically with the protected operation. Establishing the new owner must itself follow a safe coordination protocol. Numbering requests locally on each server cannot create that agreement.

State which failures the design handles

A crash-stop model assumes a failed process never returns. A crash-recovery model allows it to restart, perhaps retaining durable state while losing memory. A network partition means some participants cannot communicate even though they may all still execute.

These models change the reasoning. A restart may forget an in-memory ownership record. A partition can leave two groups convinced they should continue. Randomly corrupted or deliberately dishonest messages require still different protection; our course’s basic replication examples assume participants follow the protocol.

It can be correct to refuse writes while ownership is uncertain. That sacrifices availability during some failures to protect the promised state.

Predict the unprotected write

B receives number 8, but storage never sees it and checks no ownership numbers. Has issuing the new number alone protected the data?

Find the missing enforcement step

No. A can still submit its stale write, and storage has no rule for rejecting it. The token must reach a resource that enforces the ordering before the protected change occurs. A token in a coordinator’s log is not by itself a fence around another service.

We can now distinguish failure detection from authority. Next, define what readers should observe when requests reach different machines.

Further study: Raft’s failure assumptions and term-based leadership. Its log protocol provides a concrete example of handling crashes and partitions; the external-resource fencing example here is a separate teaching model.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter