Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

clientID

 
Jim Bedenbaugh
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm using the spawned DataServer thread reference (on the client side) for my unique client id. My client side DataClient handles all the networking issues (getConnection, lock, unliock, getRecord, etc).
The problem is this:
If I lock, read, check availablity, write and unlock, I need to pass the clientID over to the server. Problem is, the current signatures for lock and unlock don't provide for this and I'm loathe to change them.
If I call a method to set the clientID on the server side and then call a lock method that gets the clientID that was just set, RMI cannot guarantee I will get the same thread again, so I might end up using a thread that doesn't have a clientID, or worse, one that has a different clientID.
What gives? How did others handle this?
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Search for Connection and ConnectionFactory in this forum. Also refer the link that talks about Factory pattern and RMI. Basically you will have a unique remote object for every client at the server side. No need to send any id from the client. That remote object serves the client as long as the client is active.
 
Jim Bedenbaugh
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sai Prasad:
Basically you will have a unique remote object for every client at the server side. No need to send any id from the client. That remote object serves the client as long as the client is active.

Sai,
Thanks for the reply.
I do have a factory pattern in place and I return unique remote objects for each connection.
So. I guess you are suggesting using UnicastRemoteObject.getClientHost() ?
Or, did you have something else in mind?
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,

So. I guess you are suggesting using UnicastRemoteObject.getClientHost() ?

Why not just use "this"? Map the object itself to the locked record.
Hope this helps,
Michael Morris
 
Jim Bedenbaugh
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Morris:
Hi Jim,
Why not just use "this"? Map the object itself to the locked record.

But if I call the lock method from the client side, how do I know I will get the same "this" that was used to lock the record when I go to unlock it?
[ August 14, 2002: Message edited by: Jim Bedenbaugh ]
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So your remote connection should have a lock/unlock method. This should call some sort of lock manager so that it can use the map of locks. When it does, pass along "this" (the remote object) to lock and unlock and use it as the id. That way your "this"es will always be the same "this" that locked for doing the unlocking...
Sorry if that was confusing... feel free to ask more questions if it was.
 
Jim Bedenbaugh
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nate Johnson:

Sorry if that was confusing... feel free to ask more questions if it was.

One question:
In my implementation, I have a FBNServer which is bound to rmiregistry.
FBNServer returns references of DataServer( which has extended UnicastRemoteObject and implemented DataInterface - all the Data methods) to the client.
Do I have bind DataServer to rmiregistry, or am I free to make references to it as is from the client?
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Bedenbaugh:

One question:
In my implementation, I have a FBNServer which is bound to rmiregistry.
FBNServer returns references of DataServer( which has extended UnicastRemoteObject and implemented DataInterface - all the Data methods) to the client.
Do I have bind DataServer to rmiregistry, or am I free to make references to it as is from the client?

No. That is the way I did it. Your "FBNServer" is what I call the RemoteDataFactory and your "DataServer" is what I call a RemoteData object. As long as both of those objects extend UnicastRemoteObject and implement Remote, then you can get a ref to your FBNServer in your client and tell it to return a DataServer that your client can use.
[ August 15, 2002: Message edited by: Nate Johnson ]
 
Jim Bedenbaugh
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nate Johnson:

No. That is the way I did it. Your "FBNServer" is what I call the RemoteDataFactory and your "DataServer" is what I call a RemoteData object. As long as both of those objects extend UnicastRemoteObject and implement Remote, then you can get a ref to your FBNServer in your client and tell it to return a DataServer that your client can use.
[ August 15, 2002: Message edited by: Nate Johnson ]

Thanks Nate.
My confusion stemmed from the fact that I thought all remote objects had to be registered through rmiregistry and if so, then each time I called my DataServer, I would have no idea if I was getting the same thread each time, hence my concern in using the remote object as the clientID.
Thanks.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A reference of the Remote object can be returned by invoking a method on some other remote object. Reference of a Remote object is returned only if that object extends UnicastRemoteObject and implements Remote interface. You can also ask the RMI runtime to send a copy of the Remote object if that object only implements java.io.Serializable.
Therefore there are 3 ways to get a hold of objects residing at the RMI server
1) By registering the object in RMI Registry and finding it from the client using lookup()
2) Return the object reference via a method call
3) Return the copy of an object via a method call as long as the object only implements Serializable interface.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic