Lease
From Jini.org
A Lease is a basic mechanism used for fault-tolerant resource control in Jini. The essential idea behind a lease is fairly simple. When gaining access to a resource, the party asking for access makes the request for some interval of time. The grantor of the resource will then give access for some period of time that is no longer than that requested (although it may be shorter); the period of time that is actually granted is returned to the requestor as part of the lease object. A holder of a lease can request that a lease be renewed, or cancel the lease at any time. Successfully renewing a lease extends the time period during which the lease is in effect. Cancelling the lease drops the lease immediately. If a lease expires, the grantor of the lease can take an action on the resource that can free that resource, and the holder of the (now expired lease) can know that the grantor has taken that action. What the actual action taken on lease expiration should be specified as part of the description of the method called when the lease was originally given.
There are, of course, many details that have been elided in such a general description. Perhaps the best way to understand such details is to look at a paticular example.
One of the services that uses leasing is the lookup service. When a service registers with a lookup service, it requests a period of time for that registration. The lookup service will grant a lease that is the minimum of the requested time and the maximum lease duration that has been configured for that particular lookup service. It is then up to the service to renew the lease that is handed back as a result of the registration call. When renewing the lease, the service will again ask for a renewal of a particular duration, and the renewal will again be the minimum of the requested time and the maximum lease duration offered by the lookup service. A well-behaved lookup service will grant any lease renewal request that it receives. If a service wishes to end its registration with the lookup service, it will cancel the lease, and the lookup service will then drop the registration of that service.
The reason that the registrations is leased, however, is to deal with cases where the service becomes unavailable for unplanned reasons. If the service were to crash, or become unavailable because of network failure, it would not be able to cancel its registration. In such a case, the lease for the registration will expire. At that point, the lookup service will drop the registration, reflecting the fact that the service is no longer available. This behavior is specified by the lookup service, so if the service becomes available after such a lapse, it knows that it needs to re-register (rather than try to do a lease renewal) to show its availability.
A somewhat different example of leasing is the use of leases in the transaction interfaces for Jini. All transactions are leased, and those leases can be renewed. If a transaction lease expires, however, the result is that the transaction aborts. This allows the transaction manager to deal with crashed participants; it also shows that the action that is to be taken on lease expiration is dependent on the semantics of the resource that is being leased.
Leases are like keep-alive messages or heartbeats, but differ in that different resources can be given different lease durations. Thus the length of time that is allowed before failure is discovered and corrective action is taken can be determined on the basis of a negotiation between the client of the service and the service itself, rather than being set on a system-wide basis.
