wood burning stoves*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes clientID Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "clientID" Watch "clientID" New topic
Author

clientID

Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
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?


Regards,
Jim
SCJP, SCJD, SCWCD, SCEA Part I
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
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

Joined: Nov 09, 2001
Posts: 171
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

Joined: Jan 30, 2002
Posts: 3451
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


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
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

Joined: May 13, 2002
Posts: 301
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.


scwcd, scjd, scjp<br /><a href="http://natejohnson.us" target="_blank" rel="nofollow">http://natejohnson.us</a><br /><a href="http://rice.kuali.org" target="_blank" rel="nofollow">http://rice.kuali.org</a>
Jim Bedenbaugh
Ranch Hand

Joined: Nov 09, 2001
Posts: 171
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

Joined: May 13, 2002
Posts: 301
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

Joined: Nov 09, 2001
Posts: 171
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

Joined: Feb 25, 2002
Posts: 560
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: clientID
 
Similar Threads
What will the client side lock() method do?
lock/delete/unlock as atomic operation
a client could unlock a record that it has not locked?
lock and unlock
lock/unlock