Most read:
Popular archives:
JavaWorld's new look is here!
We've upgraded the site with a fresh look-and-feel, improved topical navigation, better search, new features, and expanded
community platform. Learn more about the changes to JavaWorld.
| Oracle Compatibility Developer's Guide |
| The Explosion in DBMS Choice |
TEXTBOX:
TEXTBOX_HEAD: Activatable Jini services: Read the whole series!
:END_TEXTBOX
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.
unreferenced(), and distributed garbage collection in this message to the Jini Users listopj. While orthogonal persistence may not be desirable and correct in many environments, VMs of this sort can generate ideas
about low startup latency of Java programs (including activatable Jini services) and preserving execution state across program
restartsRemoteException, why it is a checked exception and not a runtime exception, and the basic difference between remote and local method invocationsActivationGroupDesc to set up a common environment for a group