Roel De Nijs wrote:I kept the static reference in the class that's used to start the RMI-server.
Ok, now I figured out what I meant to ask you! But firstly, nice find . I've not seen this mentioned in any tutorial or book that I've read on RMI. It is obviously quite important!
You have a class that you use to start the RMI-server. Do you actually create an instance of this class or it is just a utility class with static methods?
I am guessing that it is the latter. You have a static method to start the RMI-server. That is why you have to store your RemoteBusinessLogicImpl instance as a static variable.
If the whole idea is to prevent the JVM from GC'ing (Garbage Collecting) your instance of RemoteBusinessLogicImpl then there is one more logical place to put it. Place a reference to it in your server GUI as an instance variable rather than a static.
Making the a static reference to the instance of RemoteBusinessLogicImpl is not what prevents it from being GC'd. It is keeping a reference to it that prevents the JVM from GC'ing the instance of RemoteBusinessLogicImpl . Creating a static reference is not the key point. That reference could be a static field or an instance field. The key point is creating a reference that will exist for the lifetime of the server.
You can be guaranteed that your instance of RemoteBusinessLogicImpl will not be GC'd if you assign it to an instance variable of your server GUI class.
So you would have...
Benefits of Other Approach
Nice separation of concerns. The RemoteBusinessLogic lives with the server window which it relates to - logical one-to-one association here. The registry is created - no need to wrap a one liner inside a custom class. The register-method is a static method that is only concerned with registering the remote service - it makes no sense for such a class to hold a state.
Keeping your instance of RemoteBusinessLogic alive is obviously important as you found from your testing. So making it an instance variable of your server GUI class makes it more prominent rather than holding on to it as a side effect in a utility class.
Super. Would you agree that an instance field in an object that is guaranteed to live as long as the server will also solve the problem here? One such object being the server window. Just checking that I am not missing something.
Sean Keane wrote:Would you agree that an instance field in an object that is guaranteed to live as long as the server will also solve the problem here?
If you have a gui window for your server (not everybody uses this approach) you can use an instance in the server window and then the utility class is a good alternative. Also if you want a seperate class with one well-defined purpose (registering your object) you could use the utility class alternative, because you could say it's not the responsibility of your view to register the object. And you could also reuse the utility class in your tests to register the object to test your remote business service implementation.
So the moral of the story is - keep a reference to the implementation of your remote service so that the reference stays alive for as long as the server is alive.
One option is an instance field in your server, as an instance of the server will always be alive for as long as your server is alive. Another option is to store the reference in a static field of a class that will be loaded as the server is starting up.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
and POOF! You're gone! But look, this tiny ad is still here:
Devious Experiments for a Truly Passive Greenhouse!