• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S 2.3.1 - Identifying clients uniquely in RMI

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings all-
I have a single instance of Data being shared by all the networked clients. (I have a Proxy object that is unique to each client and exists on the client JVM and each proxy holds a reference to the same single RemoteObject which in turn has the Data instance). What would be a good way to identify the clients uniquely (client JVMs uniquely) on the RMI server JVM for my locking operations.

I could use java.rmi.server.RemoteServer.getClientHost() on the RMI server JVM but then I would have to specify in my choices.txt that 2 clients cannot be launched as network clients from the same machine.

Alternatively, I am thinking about callbacks but am a little stuck. I can quite easily send a generealized update to all the clients using callbacks by registering each client with the RMI server. But then using callbacks, how do I execute a method on a specific client to get the client's unique information if that client is executing the lock method.

Any help/advice would be appreciated.

Thanks,
Arun.
 
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Arun,

What is the method signature of your lock and unlock methods in the interface provided by Sun? I ask because there are two different strategies, depending on whether or not your interface uses lock cookies...
 
Arun Subramanian
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What is the method signature of your lock and unlock methods in the interface provided by Sun? I ask because there are two different strategies, depending on whether or not your interface uses lock cookies...



Good question, Paul. Sorry, I should have mentioned that in my initial post itself. I have a single argument viz. "record number" and hence no place for a "client ID" in my lock methods.



Thanks,
Arun.
 
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hello,

I assume that your methods don't use cookies, which would make an identification easy.

Use an additional layer. Don't make Data access the file directly. Rather use an other class for this which has similar method signatures, with one difference: Whereever identification is required add an argument to the method signature. This is of type DBMain. E. g. void lock(int recno) -> void lock(int recno, DBMain whoIsThis).
Now your clients don't share the same remote object. Each of them has its own remote object. Your Data class just delegates to this new class, passing itself as an argument, e. g.

Note that when an object returned by a Remote object implements Remote itself it is not serialized back to the client: It becomes a remote object on the server side. Use a remote factory that creates the remote objects to access the database.

To summarize: You have one remote object that is a factory, one instance of some file access class that is on the server side and which does not implement Remote, and for each client there is one other remote object obtained by the remote factory.

@Moderators feel free to delete parts of my post if I gave too many hints.

Conan
 
Arun Subramanian
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

To summarize: You have one remote object that is a factory, one instance of some file access class that is on the server side and which does not implement Remote, and for each client there is one other remote object obtained by the remote factory.



Thanks, Conan. So, if I understood you correctly, the above design entails each client having it's own RemoteObject and it's own DataAccessObject? Hmmm...that would be a reasonably big change in my design considering I would now have to think about how it affects my Data methods (which are currently synchronized), LockManager etc. In my current design, on the RMI Server JVM, I only have 1 instance of the RemoteObject thereby 1 instance of Data and thereby 1 instance of the LockManager (RemoteObject has Data as a private field and Data has LockManager as a private field). I would still be interested in knowing if anyone implemented a similar design as mine and were able to identify the clients uniquely given the lock methods w/ only 1 argument.


Note that when an object returned by a Remote object implements Remote itself it is not serialized back to the client: It becomes a remote object on the server side. Use a remote factory that creates the remote objects to access the database.



I think I understood this. The unique RemoteObject for each client returned by the RemoteFactory call that the client makes still sits very much on the RMI Server JVM but a stub to that RemoteObject is returned to the client JVM. Right?

Fyi, right now, I do have an RemoteFactory that's registered w/ the RMI Registry. But instead of returning the RemoteObject when the clients call the RemoteFactory method "getInterface()", I return a serializable Proxy object to the client. Each Proxy object has a reference to the one single instance of the RemoteObject. Each Proxy object also has a copy of the database file schema of the database file on the RMI Server and so a client doesn't have to do a network operation if it's interested in knowing the schema description. So, in my design, the clients invoke the methods on their Proxy objects which in turn invoke the methods on that 1 RemoteObject on the RMI Server.


Thanks,
Arun.
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Arun,

I faced the same challenge (at first I had been assuming I could use the Thread ID to identify clients, but the friendly people here convinced me that was a bad idea) and eventually opted for the solution outlined above: create a new Data class instance for each client. I too thought that it would be a major redesign, but in the end I fixed it in a couple of hours.

Frans.
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hello,

I don't think that you have to reimplement or redesign a lot. You just have to refactor a little.

Your current Data class (the one that accesses the file) just has to be RENAMED and the signatures of the methods have to be changed to accept a DBMain (to identify the client). Your new Data class is simple, because it just delegates to your old Data class.

Conan
[ March 26, 2005: Message edited by: Conan Elvitaro ]
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi.... I'm in the same boat as Arun, and while I understand the factory concept at a more abstract level, I'm failing on a level of detail. When you say a RemoteObject and DataAccessObject for each client is that a newly registered and binded object for each client then? I'd would be really grateful if somebody could expand on this...obviously without giving away too much. I to have a single RemoteObject instance in my design at the moment, but have come across a lot of recent discussion on Factory's and a RemoteObject per client.

Many thanks,


Paul.
 
Arun Subramanian
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Paul-
Based on the suggestions by Conan, Frans in this thread and also the observation from other threads in this forum that this indeed is a very popular design, I have changed my design to hand off each client their own RemoteObject. I specially need to do this because my locking methods don't have a provision for a "client ID" parameter in the parameter list.

When you say a RemoteObject and DataAccessObject for each client is that a newly registered and binded object for each client then?


No, you register and bind only 1 object or service w/ the RMI registry i.e. the RMIFactory object. The RMIFactory has a method that the clients call and which returns the RemoteObject (In this method, I create the RemoteObject and I return an interface to the client that the RemoteObject implements. Fyi, in my design, the LocalObject which is returned in the stand alone mode also implements the same interface so that client call to return the local/remote object is generic irrespective of the mode). So, the RemoteObject and the RMIFactory both extend UnicastRemoteObject and implement Remote but it's only the RMIFactory that's registered and bound.

Also, this is a good read...Link to thread w/ the RMI Factory link

Thanks,
Arun.
 
reply
    Bookmark Topic Watch Topic
  • New Topic