GeeCON Prague 2014*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Static reference to my remote service implementation to avoid java.rmi.NoSuchObjectException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Static reference to my remote service implementation to avoid java.rmi.NoSuchObjectException" Watch "Static reference to my remote service implementation to avoid java.rmi.NoSuchObjectException" New topic
Author

Static reference to my remote service implementation to avoid java.rmi.NoSuchObjectException

Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

I was reading about the need to keep a static reference to your remote service implementation in order to avoid it being garbage collected and thus causing an java.rmi.NoSuchObjectException.

So adding a static field prevents the GC from removing this object. That makes sense. But I am just wondering where did people place this static field? Was the field in a static class?


SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5300
    
  13

I kept the static reference in the class that's used to start the RMI-server.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Roel De Nijs wrote:I kept the static reference in the class that's used to start the RMI-server.


Was that a static class?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5300
    
  13

Sean Keane wrote:Was that a static class?

No
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Static class? Apologies, disregard that. I think I was still asleep !
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

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.

Another Approach

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.

An Example

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.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5300
    
  13

Sean Keane wrote:Do you actually create an instance of this class or it is just a utility class with static methods?

It's a utility class with a static method.
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

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.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5300
    
  13

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.
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

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.
 
GeeCON Prague 2014
 
subject: Static reference to my remote service implementation to avoid java.rmi.NoSuchObjectException