Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Activatable Jini services, Part 2: Patterns of use

The RMI activation framework can produce self-sufficient and flexible Jini services

By Frank Sommers, JavaWorld.com, 10/27/00

In Part 1 of this series, I defined activation as the process of creating and exporting an object via the RMI activation system, making it available for remote method calls. I also presented the chief goal of the RMI activation system: to help remote objects manage their computational resources. The JDK's activation mechanism does just that; it helps objects manage their computational resources, it does not do it for them. It is up to the developer of Jini services to properly utilize RMI activation to support resource management. In Part 2, I will present the consequences of Jini activation and some helpful patterns of use. The first important area to consider is deactivation.

TEXTBOX:

TEXTBOX_HEAD: Activatable Jini services: Read the whole series!

• Part 1: Implement RMI activation

• Part 2: Patterns of use

:END_TEXTBOX

When to deactivate

An object informs the activation group that it is no longer active by calling Activatable.inactive(), which essentially calls the current activation group's inactiveObject() method. If no remote method calls to the object are pending -- i.e., the object really is inactive -- the group unexports the object and notifies its monitor. Thereafter, the activation monitor will consider the object's remote references as stale, causing activate() requests with the object's activation ID to trigger the activation protocol (described in Part 1).

If Activatable.inactive() succeeds, and if the group has no more active objects and is not activating objects, the activation system will shut down the group's Java VM. If an object fails to call Activatable.inactive(), it will never be garbage-collected because the activation group holds strong references to every object it creates. (Hence, if that object is the last one running in the Java VM, the Java VM will not shut down either.) The rules for garbage collection still hold, though: the object needs to make sure that it has no nondaemon threads running, and that it nulls out enough references to be eligible for garbage collection.

The remote object decides when to call inactive(); this decision warrants some stipulations. One requirement for calling this method is that the remote object should not handle remote method calls. Also, reactivating the object should not require more effort than keeping it active for long periods of time. For instance, if a server only runs a few activatable Jini service implementations -- each of which might receive a remote method call once every few hours -- and the server is loaded lightly, running those objects continually would be the best option.

The last deactivation issue we'll consider is leases. In the Jini programming model, services typically lease their resources. For instance, not only does LoanApprovalService lease its residency in lookup services, but clients that wish to use this service lease their access to it as well. When first contacted by a client, the service should return a Registration object that contains a lease and the remote service reference, not a direct remote reference to itself.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.