Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

One Remote Instance serves all clients?!

 
Sandra Baker
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I am using RMI, and have the server provide only one remote instance as "service center". Every client only needs to lookup for this instance, and start their requests. The server does not track which client is making what request.
Does this sound like a reasonable design to you? Is there any shortcoming of doing this way? I cannot think of any, can someone give some insights?
I guess my doubt is that if we create a remote instance for every client, what if there are tens or millions clients, aren't we need to create million objects on the server?......many thanks
[ September 09, 2002: Message edited by: Sandra Baker ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sandra,

Hi, I am using RMI, and have the server provide only one remote instance as "service center". Every client only needs to lookup for this instance, and start their requests. The server does not track which client is making what request.
Does this sound like a reasonable design to you? Is there any shortcoming of doing this way? I cannot think of any, can someone give some insights?

You have two problems here:
1.) Since you only have the one Remote object that all clients access, you have created a bottleneck at the clients' entry point unless you implement some sort of threading scheme. It is also more difficult to protect Data from concurrent modification with a single object without creating more bottlenecks.
2.) If you don't know which client has locked a particular record, you can't comply with the requirement that unlock() ignore a request to unlock a record that it did not lock.
To solve these problems, you should consider using a ConnectionFactory and from it, issue each client its own unique connection object. You can search this forum and find volumes of information on this subject.
Hope this helps,
Michael Morris
 
Sandra Baker
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot, Michael. I did try to look up the forum and found this thread. I have exactly the same question as this post, but not really getting what the reply meant:
http://www.coderanch.com/t/180339/java-developer-SCJD/certification/confused-remote-object
"by extending Remote you have a version for each user. "
Can you please explain it, if you could? Thanks
[ September 09, 2002: Message edited by: Sandra Baker ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sandra,
I think as Mark pointed out that version was probably a poor choice of terms, a single instance would be a better term.
The ConnectionFactory in a nutshell goes something like this:
You create a DataConnection (or whatever you want to call it) interface that extends Remote and has a single method named getConnection() (or whatever you want to name that) that returns a DataInterface which also extends Remote. You have a class named ConnectionFactory which implements DataConnection and is bound to the RMI registry. Clients then lookup this object thru Naming and then call getConnection() which returns a new (and unique) DataInterface implemetation. So each client has its very own object to access the database and can be uniquely IDed by that object.
Hope this helps,
Michael Morris
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic