pls. Lisa Foster and friends

[shanmugam soundrapandian]

how to do lock method with client ID using RMI. i have finished lock method without client ID.most recent threads are talking about client ID.
can you please kindly help me how to find Client ID and what is the use of that?
regards
soundar

[Rick Fortier]

Originally posted by shanmugam soundrapandian:
how to do lock method with client ID using RMI. i have finished lock method without client ID.most recent threads are talking about client ID.
can you please kindly help me how to find Client ID and what is the use of that?
regards
soundar

I would also like to know this too. I have seen recent posts of people using Client ID successfully, but they were not using RMI. Some people were saying that they were placing the thread object in their locking array and using that to compare it with the person who is trying to do the unlock. But I have also read in other threads where it is not guaranteed that the client will use the same connection.
My instructions are "If an attempt is made to unlock a record that has not been locked by this connection, then no action is to be taken".
Thinking about this again, I implemented a singleton class to contain a list of all the locks (in a syncronized HashMap), what if I also maintained another list of locks that this connection has? I think that is what I will do.
Ok, so I will be maintaining one global list in a singleton class containing a list of all locks, and a list for each client that lists their current locks. Then when unlock is called, I will first look in the client's personal list to see is they locked it before allowing them to unlock the global one. Since my instructions clearly state that it must occur within the same connection.
The caveat is, if the client dies before calling unlock, then the record will remain locked. I think that I might put a "time to expire" value in my global list. So that if a client dies, then eventually it will be unlocked by the first client that wishes to lock the file after the time out period.
Does this make sense?

[Lisa Foster]

I could be wrong but off the top of my head I would look at getUID() method for RMI I believe that will return a unique thread ID for each RMI client(thread).

[Aleksey Matiychenko]

With RMI there is no guaranty that a thread will be reused by the smae client.
I have used CustomSocketFactory to supply client id.

[Conor Allen]

Two things:
Quite a number of people have not identified the client at all ... just relied on the clients behaving ... i.e. adhering to a lock/read/modify/unlock constraint. If this is the case you never need to identify the client because the lock method will block any thread that requests a lock untill that lock has been released. I'm not sure what I'm gonna do yet ... I've implemented the locking without the client being identified. Identifying the client would make things more complicated. The requirements say 'keep it simple'.
Other people have altered the signature of the lock/unlock methods to accept a token which represents the locker. This seems like a simple solution of the client definitely meends to be identified.
Aleksey ... what did you do to get the client id from the 'CustomSocketFactory'? Is this not a compley solution to the question?
Anyway, just my thoughts
Conor
P.S. Guess that was three things ....
[This message has been edited by Conor Allen (edited June 07, 2001).]
[This message has been edited by Conor Allen (edited June 07, 2001).]

[Peter den Haan]

What you can also do is give each client its own server-side object which uniquely identifies it -- call it DataConnection. This object might well implement the Data interface.
Also note that RMI has a distributed garbage collection feature which can take care of the cleanup when a client dies on you. For free.
- Peter

[This message has been edited by Peter den Haan (edited June 07, 2001).]

[Andrew Griffin]

Aleksey,
I have been playing with custom socket factories lately and have not had much success - I get AccessControlExceptions, etc.
Without giving your solution away, can you offer me a hint?
If not, I fully understand.
Thank you
Andrew

[shanmugam soundrapandian]

Thanks friends
sorry.. i am not convinced still. still i am struggling to get client Id through customsocketfactory or Rmi..
let me go through in depth.
if some one find appropriate way pls let us know
regards
soundar

[Peter den Haan]

Isn't a CustomSocketFactory far too complicated for the purpose? - why not simply give each client its own server-side object to talk to?
- Peter

[Conor Allen]

Hmm...
Is there any guarentee that the server side object that they use is not resued by other clients? i.e. does rmi view server side rmi objects as stateless?
Conor

[Peter den Haan]

RMI objects are like any other object. If you want to create a separate one for each client, you can do it like this. Bind a connection factory into the nameserver. The client resolves the factory, calls it to create a connection object, and then uses that connection object to access the database. Every connection is a unique server-side object.
- Peter

[Akanimo Udoh]

On the issue of a clientID for the RMI clients why is it that no one has considered the getClientHost() method of the RemoteObject class (from which UnicastRemoteObject and Activatable are derived) ? This is better than trying to use the thread id's which i've found can/will change between RMI calls from the clients.
The call returns the 'host name of the current client'. And without and modification of the method signatures!
Thots anyone?
Akanimo.

[Aleksey Matiychenko]

What happens if the tester runs two clients from the same machine?