3

I have been using java RMI for a while now but I couldn't figure out if the RMI Remote Stubs (on the server side) are singleton? The reason I ask is:

lets assume that one of the RMI implementation methods lower down in the chain of calls have a synchronized method. If for some reason the logic in the Synchronized Method is messed up (or hangs), the future RMI calls (from the client) will hang too while trying to get access to that synchronized method. This will hold true only if the RMI stubs are going to be singleton. If a new object is created on the server side at every remote call from the client, this won't be a problem because than the methods are being called from a different object and synchronized method won't be an issue anymore.

Long story short. I am trying to understand how JVM internally maintains rmi remote objects on the server side and if they are singleton. I tried many different javadocs but they don't explicitly mention this anywhere.

Any and all help is appreciated !

EDIT Based on some questions and comments, I am refining the question: my real question is, does RMI on the server side happen to keep some kind of an object pool based on what one object you export and register ? Can you bind more than one object of the same type with the same name (somewhat simulating an object pool where RMI can give me any of the objects that I registered) or in order to have multiple instances of the same object, I will have to register them with different names

shahshi15
  • 2,332
  • 2
  • 17
  • 23

4 Answers4

4

First of all, the "stub" is a client-side concept, there are no stubs on the server.

As for the remote objects themselves, the RMI system doesn't instantiate the objects for you, it's up to you to create instances and export them. You create one instance of the object, export that object, and bind it in the registry under a particular name. All calls on client stubs obtained from that same name in the registry will ultimately end up at the same object on the server.

Can you bind more than one object of the same type with the same name (somewhat simulating an object pool where RMI can give me any of the objects that I registered)

No, you can only bind one object in the registry under a given name. But the object you bind could itself be a proxy to your own object pool, for example using the Spring AOP CommonsPoolTargetSource mechanism.

Ian Roberts
  • 114,808
  • 15
  • 157
  • 175
  • You can create as many instances S you like. The are therefore not singletons at all. – user207421 Sep 12 '14 at 23:09
  • @Ian Roberts: So what you are saying is if I instantiate multiple objects of the same class, export those objects and bind them in the registry with different names, it will work .. I think I get that part. But I guess my real question was does RMI on the server side happen to keep some kind of an object pool based on what one object you created? (I guess I will update my question with this as well) – shahshi15 Sep 13 '14 at 06:04
  • @EJP The point I was trying to make was the same as yours - the RMI infrastructure doesn't create any of your remote objects itself, it simply routes calls to whatever objects you choose to export. If you want to bind an object in the registry that is backed by a pool of server-side objects then it's up to you to do the pooling yourself, and use a suitable proxy object as the (single) remote object you bind in the registry under that name. Remote objects are no different from local ones in that respect. – Ian Roberts Sep 13 '14 at 14:24
  • I was commenting on the words 'they are singletons' which you have now removed. – user207421 Sep 13 '14 at 20:21
  • I have a much better picture of how this whole thing works. Thanks guys! Appreciate the help! – shahshi15 Sep 16 '14 at 20:29
2

RMI its based on proxy design pattern.

See what says here

A RMI Server is an application that creates a number of remote objects. An RMI Server is responsible for:

  1. Creating an instance of the remote object (e.g. CarImpl instance = new CarImpl());
  2. Exporting the remote object;
  3. Binding the instance of the remote object to the RMI registry.
Luciana Campello
  • 121
  • 4
2

Stubs are not singletons, but your question is really about the server-side objects. They are not singletons either, unless you implement them that way yourself. RMI doesn't do anything about that whatsoever.

EDIT Based on some questions and comments, I am refining the question: my real question is, does RMI on the server side happen to keep some kind of an object pool based on what one object you export and register?

No.

Can you bind more than one object of the same type with the same name

No.

I will have to register them with different names

You don't have to register them at all. You need one singleton remote object bound into the Registry: consider that as a factory method for further remote objects, which are returned as results from its remote methods. For example, a remote Login object is bound in the Registry and has a single login() method that returns a remote session object, a new one per login, with its own API.

user207421
  • 289,834
  • 37
  • 266
  • 440
  • So how does it work? If I register multiple server-side objects (same object) with the same name, It will be multiple objects instead of one singleton? Or will I have to register multiple server-side objects (of the same implementation class) with different names? – shahshi15 Sep 13 '14 at 06:02
  • Remote objects only have names if you bind them into the Registry. That's only one way to acquire them. You can also return them as results of remote methods. Consider for example a remote session object. You would have one per client, and you would return them from some kind of Login object, a new one per login request. – user207421 Sep 13 '14 at 07:53
0

From the Java docs:

http://docs.oracle.com/javase/7/docs/platform/rmi/spec/rmi-arch3.html

A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe.

Yes, the server side method is synchronized. The implementation is platform-specific. You cannot assume anything else about threading. And you certainly cannot assume whether or not the remote object is a singleton.

Also, it might be useful to look at Remote Object Activitation:

http://docstore.mik.ua/orelly/java-ent/jenut/ch03_06.htm

http://docs.oracle.com/javase/7/docs/api/java/rmi/activation/package-summary.html

FoggyDay
  • 10,517
  • 4
  • 24
  • 33