Leasing is the mechanism used between applications to give access to resources over a period of time in an agreed manner
Leases are requested for a period of time.
In distributed applications, there may be partial failures of the network
or of components on this network. Leasing is a way for components to
register that they are alive, but for them to be ``timed out'' if they
have failed, are unreachable, etc.
In Jini, one use of leasing
is for a service to request that a copy be kept on a lookup service
for a certain length of time for
delivery to clients on request. The service requests a time in the
ServiceRegistrar's method register().
Two special values of the time are
Lease.ANY - the service lets the lookup
service decide on the time
Lease.FOREVER - the request is for a lease that never expires
The lookup service acts as the granter of the lease,
and decides how long it will actually create the lease for.
(The lookup service from Sun typically sets the lease time as
only five minutes.)
Once it has done that, it will attempt to ensure that the request
is honoured for that period of time. The lease is returned to the
service, and is accessible through the method getLease()
of the ServiceRegistration object. These objects are shown
in figure 8.1
ServiceRegistration reg = registrar.register();
Lease lease = reg.getLease();
The principal methods
of the Lease object are
package net.jini.core;
public interface Lease {
void cancel() throws
UnknownLeaseException,
java.rmi.RemoteException;
long getExpiration();
void renew(long duration) throws
LeaseDeniedException,
UnknownLeaseException,
java.rmi.RemoteException;
}
getExpiration() is the time in milliseconds
since the beginning of the epoch
(the same as in System.currentTimeMillis()).
To find the amount of time still remaining from the present, the current time
can be subtracted from this:
long duration = lease.getExpiration() - System.currentTimeMillis();
A service can cancel its lease by using cancel().
The lease communicates
back to the lease management system on the lookup service which
cancels storage of the service.
When a lease expires, it does so silently. That is, the lease granter
(the lookup service) will not inform the lease holder (the service)
that it has expired.
While it might seem nice to get warning of a lease expiring so that it
can be renewed, this would have to be in advance of
the expiration (``I'm just about to expire, please renew me quickly!'')
and this would probably be impractical.
Instead, it is upto the service to call renew()
before the lease expires if it wishes the lease to continue.
SECTION LOST HERE ON LEASE RENEWAL MANAGER???
The servis in milliseconds.
The expiration time is since the epoch, whereas the
duration time is from now.
Generally leases will be renewed and the manager will function
quietly. However, the lookup service may decide not to renew a
lease and will cause an exception to be thrown. This will be caught
by the renewal manager and will cause the listener's notify()
method to be called with a LeaseRenewalEvent as
parameter. This will allow the application to take corrective
action if its lease is denied.
The listener may be null.
All of the above discussion was from the side of a client that receives a lease, and has to manage it. The converse of this is the agent that grants leases and has to manage things from its side. This section contains more advanced material which can be skipped for now: it is not needed until the chapter on ``Remote Events''. An example of use is given in the chapter on ``More Complex Examples''.
A lease can be granted for almost any remote service, any one where one object wants to maintain information about another one which is not within the same virtual machine. Being remote, there are the added partial failure modes such as network crash, remote service crash, timeouts and so on. An object will want the remote service to keep ``pinging'' it periodically to say that it is still alive and wants the information kept. Without this periodic assurance, the object may conclude that the remote service has vanished or is somehow unreachable, and it should discard the information about it.
Leases are a very general mechanism for one service to have confidence in the existence of the other for a limited period. Being general, it allows a great deal of flexibility in use. Because of the possible variety of services, some parts of the Jini lease mechanisms cannot be given totally, and must be left as interfaces for applications to fill in. The generality means that all the details are not filled in for you, as your own requirements cannot be completely predicted in advance.
A lease is given as an interface
and any agent that wishes to grant leases must implement this interface.
Jini gives three implementations, an AbstractLease with
subclass a LandlordLease which in turn has a subclass
ConstrainableLandlordLease
A main issue in implementing a particular lease class lies in setting a policy for handling the initial request for a lease period, and in deciding what to do when a renewal request comes in. Some simple possibilities are
Always grant the requested time
Ignore the requested time and always grant a fixed time
There are other issues, though. Any particular lease will need a time-out mechanism. A group of leases can be managed together, and this can reduce the amount of overhead of managing individual leases.
An abstract lease gives a basic implementation of a lease, that can almost be used for simple leases.
package com.sun.jini.lease;
public abstract class AbstractLease implements Lease, java.io.Serializable {
protected AbstractLease(long expiration);
public long getExpiration();
public int getSerialFormat();
public void setSerialFormat(int format);
public void renew(long duration);
protected abstract long doRenew(long duration);
}
Lease interface, with three provisos: firstly, the constructor
is protected,
so that constructing a lease with a specified duration
is devolved to a subclass. This means that lease duration policy must be
set by this subclass. Secondly, the renew() method calls
into the abstract doRenew() method, again to force a
subclass to implement a renewal policy. Thirdly,
it does not implement the method
cancel(), so that this must also be left to a subclass.
So this class implements the easy things, and leaves all matters of
policy to concrete subclasses.
Section on landlord package and later stuff removed for now till I get it properly sorted out
Leasing allows resources to be managed without complex garbage collection mechanisms.
Leases received from services can be dealt with easily using LeaseRenewalManager.
Entities that need to hand out leases can use a system such as the landlord
system to handle these leases.
If you found this chapter of value, the full book is available from APress or Amazon . There is a review of the book at Java Zone . The current edition of the book does not yet deal with Jini 2.0, but the next edition will.