LR.1. Introduction

Leasing is a key concept in the Jini architecture; in general, Jini technology-enabled services (Jini services) grant access to a resource only for as long as the clients of those Jini services actively express interest in the resource being maintained. This pattern is in contrast to many other systems, in which access to a resource is granted until the client explicitly releases the resource. Using a leasing model generally makes a distributed system more robust by allowing stale information and services to be cleaned up, but it also places additional requirements on clients and services.

A client of a leased service may run into difficulties if that client deactivates. Unless the client ensures that some other process renews the client’s leases while it is inactive, or that the client is activated before its leases begin to expire, the client will lose access to the resources it has acquired. This loss can be particularly dramatic in the case of lookup service registrations. A service’s registration with a lookup service is leased—if the service deactivates (maybe to conserve computational resources on its host) and it does not take appropriate steps, its registrations with lookup services will expire, and before long it will be inaccessible. If that service becomes active only when clients invoke its methods, it may never become active again, because at this point new clients may not be able to find it.

The need to renew leases creates a constant load on clients, servers, and the network. Although batching lease renewals can help (see The Jini Technology Core Platform Specification, “Distributed Leasing”), a given client is unlikely to have very many leases granted by any one service at any given time, thus reducing the opportunities for meaningful batching.

This additional load may be an especially great burden on clients that always have the ability to access the network but cannot be continuously connected. A cell phone always has the ability to connect; however, being connected all the time will drain its batteries and accumulate airtime charges. One or two leases may not pose a problem, but a large number of leases could force the phone to be on the network all the time.

A lease renewal service can help mitigate these problems. Clients that wish to become inactive can pass the responsibility for renewing the leases they have been granted to a renewal service. Those clients can then deactivate without risk of losing access to the resources that they have acquired. Clients that have continuous access to the network but cannot be continuously connected, such as the cell phone described previously, can also register with a renewal service that can be continuously connected. The renewal service will renew the client’s leases, allowing the client to remain disconnected most of the time. Lastly, if multiple clients pass their leases to a given renewal service, more opportunities for batching renewals will be created.

Like other Jini services, the lease renewal service will grant its services for only a limited period of time without an active expression of continuing interest. To break the recursive cycle that would otherwise result, the renewal service provides an optional event that is triggered before the leases that it grants expire. This event gives activatable processes that have deactivated the opportunity to wake up and renew their lease with the renewal service. Although it may seem odd for the lease renewal service to lease its resources, it is very important that it does so. If it did not, then the lease renewal service could be used to subvert the leasing model.

Lease renewal services are likely to grant longer leases than other Jini services. In some cases the lease may be so long that the client will not need to worry about renewing the lease at all. In other cases the lease may be long enough that a client that deactivates will rarely need to reactivate for the sole purpose of renewing its lease with the renewal service. In any case, the leases that the renewal service grants are likely to be sufficiently long such that the actual renewal calls do not place a significant additional load on the client, the renewal service, or the network.

LR.1.1. Goals and Requirements

The requirements of the set of classes and interfaces in this specification are:

• To provide a service for renewing leases

• To provide this service in such a way that it can be used by activatable processes that deactivate

• To provide this service in a way that does not overly weaken the leasing model

The goals of this specification are:

• To describe the lease renewal service

• To provide guidance in the use, deployment, and implementation of the lease renewal service

LR.1.2. Other Types

The types defined in the specification of the LeaseRenewalService interface are in the net.jini.lease package. The following object types may be referenced in this chapter. Whenever referenced, these object types will be referenced in unqualified form:

java.io.IOException 
java.rmi.MarshalledObject 
java.rmi.RemoteException 
java.rmi.NoSuchObjectException 
net.jini.core.lease.Lease 
net.jini.core.lease.UnknownLeaseException 
net.jini.core.event.RemoteEvent 
net.jini.core.event.RemoteEventListener 
net.jini.core.event.EventRegistration