Leases
A lease is ownership with a limited lifetime. It lets one client hold a resource safely and, if that client fails, guarantees the resource is released so another client can take over — which is what makes it the foundation for coordination in Clustron Zaris.
The core idea
A lease combines two properties that are hard to get right on their own:
exclusive ownership + automatic expiration
Ownership ensures that only one client controls a resource at a time. Expiration ensures the system recovers on its own if that client disappears. Together they give you time-bound ownership: you hold the resource for as long as you keep the lease alive, and no longer.
Why leases exist
In a distributed system, failure is normal, not exceptional. Processes crash, machines go down, and network connections drop — often without warning and without a chance to clean up. A resource guarded by a plain lock is dangerous in this world: if the owner dies while holding the lock, the lock is never released, the resource stays stuck forever, and no other client can tell whether it is safe to take over.
A lease removes that trap by making ownership time-bound. Because every lease expires unless it is renewed, ownership can never become permanent by accident. The system heals itself instead of waiting for manual intervention.
The lease lifecycle
A lease moves through a predictable lifecycle, and understanding it is enough to predict how the system behaves under both normal operation and failure:
Acquire → Active → Renew (optional) → Expire → Released
You acquire a lease for a chosen duration, and it becomes active immediately. While it is active, you own it and can safely operate on the resource it guards. Before it expires you may renew it, which resets the expiration timer and keeps you the owner for another interval. If you stop renewing, the lease expires automatically and ownership is released. Once released, another client is free to acquire it.
The renew step is the heartbeat of the model: as long as a healthy client keeps renewing, it stays the owner; the moment it can no longer renew — because it crashed or lost the network — the clock runs out and ownership moves on.
A concrete example
Consider a background worker processing jobs. Worker A acquires a lease and starts processing, renewing the lease as it works. If Worker A crashes mid-job, it stops renewing, the lease expires, and the job becomes available again. Worker B acquires the lease and takes over. No operator has to notice the failure and no cleanup script has to run — recovery is automatic.
Binding keys to a lease
A key can be attached to a lease so that its existence is tied to that ownership. While the lease is active, the key exists; when the lease expires, the key is cleaned up automatically along with it.
This turns a lease into a way to represent live state that disappears when its owner does. It is well suited to temporary ownership, resource tracking, and presence — for example, a worker that writes a lease-bound key to announce it is alive, and whose key vanishes the instant it stops renewing.
Behavior under failure
Leases are built so that failure resolves safely on its own. If a client crashes, loses its network connection, or simply stops renewing, the outcome is the same: the lease expires. From that the system provides two guarantees you can rely on — ownership is eventually released, and no stale ownership is left behind. You never have to reason about a resource that is owned by a process that no longer exists.
Leases compared with locks
A lease is like a lock, but safer under failure. A traditional lock holds ownership until it is explicitly released, so a crashed owner can leave it held forever and deadlock everyone else. A lease holds ownership only until it expires, so failure resolves itself.
This is why coordination in Clustron Zaris is built on leases: locks here are lease-backed, which means they inherit automatic release and cannot deadlock because an owner died. You get exclusive access without the classic risk that comes with it.