Thank you all.
Sai: Also, you could use the remote implementation object as the key to the HashTable instead of having a seperate clientId.
Do you mean using Thread.currentThread().getName()? I tried this, and it works. The function returns a string of this format: "RMI TCP Connection(9)-10.10.53.80", where the number within the brackets (9) differs if there are multiple clients on the same computer. Could I rely on this being unique every time? It would save me generating userId's.
Peter: Arguably your lock() method has a bug, it really should ignore attempts to lock the same record twice.
Why? If a client tries to lock a record that's already in the the map, it means that it's "taken" and the client should wait untill it's released. I do however check whether the same client already has a lock on the record, but omitted it for clearity...
your problem might be that you're calling LockManager from within synchronized methods in Data, and your lockMap.wait() only releases the monitor lock held on lockMap, not the one on Data. You must either call LockManager from a non-synchronized Data method, or synchronize everything on Data.
Hooray, found it! I had ehem... for unknown reasons synchronized the lock and unlock methods in the server class.
Rene: the lockMap.get(recordInt) returns the value (a string in this case) pointed to by the key, not the key.
Appreciate all your contributions. Well, back to testing. Thanks.
Cheers,
Amund