Forums Register Login

clientID

+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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?
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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?
+Pie Number of slices to send: Send
 

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 ]
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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.
The fastest and most reliable components of any system are those that are not there. Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1005 times.
Similar Threads
What will the client side lock() method do?
lock/unlock
a client could unlock a record that it has not locked?
lock/delete/unlock as atomic operation
lock and unlock
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 14:06:38.