Section 4: No lock() on Purpose - API Design (with Pushback)
Executive Summary: The whole server-side API is seven calls: create, delete, exists, getData, setData, getChildren and sync. Each comes in synchronous and asynchronous forms, and none blocks. Sam's config bump, setData("/config/settlement/batch-size", "800", 7), either moves the znode to version 8 or fails with BadVersion. Every missing feature is deliberate: no lock(), watches that fire once and carry no data, reads that can be stale, values kept to kilobytes. Each answer to the interviewer's pushback comes back to one rule: the server never waits on a client.
Interviewer: "Section 3 sized the load. Show me the interface. What does a service like Sam's actually call?"
You: "Seven calls on a tree of paths. I'll list them, then defend the features I left out, because you'll ask about those."
The Seven Calls
| Call | Arguments | Returns | Can set a watch? |
|---|---|---|---|
create |
path, data, flags (ephemeral, sequential) | the created name (with its sequence suffix) | No |
delete |
path, expected version | ok, or BadVersion / NoNode / NotEmpty (it still has children) |
No |
exists |
path, watch | stat, or null | Yes (fires on create, delete, change) |
getData |
path, watch | data + stat (incl. version) | Yes (fires on change or delete) |
setData |
path, data, expected version | new stat, or BadVersion |
No |
getChildren |
path, watch | list of child names | Yes (fires when the child set changes, or the parent itself is deleted) |
sync |
path | returns once this server has applied every write the leader had proposed when it handled the sync | No |
(In the Java client, sync has long been asynchronous only; you pipeline it ahead of the read.)
Four details carry most of the weight:
- Versions are the concurrency control. Every update names the version it expects; −1 skips the check. That is compare-and-swap with no lock and no lease.
- Flags are the failure detector. An ephemeral znode dies with its session; a sequential one gets a monotonically increasing counter appended. Together they produce Sam's election znodes
n_0000000041,…42and…43. - Watches ride on reads. You read, and ask to be told when what you read changes.
- Every call has an async form. Requests pipeline, results arrive via callbacks, and FIFO client order still holds.
Multi-op, which applies several of these calls as one atomic batch, came later. Section 12 covers it.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson