Lease (computer science)

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (October 2012) (Learn how and when to remove this message) This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (October 2012) (Learn how and when to remove this message) (Learn how and when to remove this message)

In computer science, a Lease is a contract that gives its holder specified rights to some resource for a limited period. Because it is time-limited, a lease is an alternative to a lock for resource serialization.

A traditional resource lock is granted until it is explicitly released by the locking client process. Reasons why a lock might not be released include:

• The client failed before releasing the resources
• The client deadlocked while attempting to allocate another resource
• The client was blocked or delayed for an unreasonable period
• The client neglected to free the resource, perhaps due to a bug
• The request to free the resource was lost
• The resource manager failed or lost track of the resource stated

Any of these could end the availability of an important reusable resource until the system is reset. By contract, a lease is valid for a limited period, after which it automatically expires, making the resource available for reallocation by a new client.

The term 'lease' was applied to this concept in a 1989 paper by Cary G. Gray and David R. Cheriton,^[1] but similar concepts (expiring tokens^[2] and breakable locks with timeouts^[3]) had been used in prior systems.

Leases are commonly used in distributed systems for applications ranging from DHCP address allocation to file locking, but they are not (by themselves) a complete solution:

• There must be some means of notifying the lease holder of the expiration and preventing that agent from continuing to rely on the resource. Often, this is done by requiring all requests to be accompanied by an access token, which is invalidated if the associated lease has expired.
• If a lease is revoked after the lease holder has started operating on the resource, revocation may leave the resource in a compromised state. In such situations, it is common to use Atomic transactions to ensure that updates that do not complete have no effect.