Working with RMI and Jini today and I found a few tidbits that I needed to set down somewhere for future reference.

1. The RMIServer assigns a unique identifier whenever a remote object is registered (UnicastRemoteObject.export() or via extension). This is the class ObjID and it uses the class UID to store the server/host namespace of the Object.

2. Registering multiple instances of the same class is legal and clients will be capable of finding all instances even if those instances are not explicitly named. This is done in an implementation specific manner, which I’d assume is round robin or least referenced object, unless the client is using the UID for the lookup (e.g. is using a custom naming system that maps an application specific name to a remote instance) (remote instance here is in fact remote stub).

3. A remote instance can be used simultaneously by multiple clients, making the need for thread safety paramount.

It appears that Jini’s lookup cache uses the remote ObjID to store instances. I haven’t verified this completely, but it is the only way I can explain the behavior of the LookupCache.

This means that the same remote instance can not be published using two separate attribute sets. Each distinct publication into the lookup service (Jini remote lookup service) must be with a unique remote object instance.

The test I have that has been failing publishes a remote object using RMI and then publishes that same instance into the Jini lookup server twice using two different attribute sets. The Jini lookup service responds correctly by assigning the remote object two separate service IDs. However, on the client the LookupCache only finds one of the two services. This implies that the lookup cache is caching based on some type of unique identifier of the remote instance. The only thing that RMI has for that is the ObjID class. Therefore, I have to assume that the lookup cache is using the ObjID class as part of the cache key or as the only cache key.