RMI & record locking..

Hi,
I have noticed that many of my friends in this group are changing the signature of lock(int) to lock(clientID,int), where clientID is the unique ID assigned to the remote client using a factory (probably). Will it be correct if I enter the locking information into a HashMap with the Thread.currentThread() as the key and record value as the value. If I adopt this way, I could manage to implement lock() and unlock() without changing the method signature.But, in this case, I am assuming that there will be a unique Thread for servicing each client. Is this assumption correct? Please let me know about it.. Thanking You..
best regards,
Jacob George

RMI does not guarentee that you will get the same thread for consectutive remote calls... so you can not use that as your id.
What most people do is use a connection factory that returns new remote objects to the clients. Then the remote object (this) can be used as the id.

Hi Jacob,

Will it be correct if I enter the locking information into a HashMap with the Thread.currentThread() as the key and record value as the value. If I adopt this way, I could manage to implement lock() and unlock() without changing the method signature.

Nate's right, can't trust the thread for id in RMI. Also you don't have to change the lock and unlock signatures in you public Data interface. You still call lock(record) and unlock(record) from the client, then the remote implementation object passes that call on to lockManager.lock(record, this) and lockManager.unlock(record, this).
Hope this helps,
Michael Morris

Hi,
ThankYou very much for u'r help. I will have the locking information with 'this' as the key and in that case I wont have to change my method signature. Once more thanks for the tip.
regards Jacob