Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Regards, Rene Larsen
Sai: Also, you could use the remote implementation object as the key to the HashTable instead of having a seperate clientId.
Peter: Arguably your lock() method has a bug, it really should ignore attempts to lock the same record twice.
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.
Seconding SP -- it doesn't work. At all. RMI does not give any guarantees about how or if threads are associated with callers.Originally posted by Amund Frislie:
Do you mean using Thread.currentThread().getName()? I tried this, and it works.
Alright, in that case forget what I said, erm, wrote.Why [does the lock() method have a bug]? [...] I do however check whether the same client already has a lock on the record, but omitted it for clearity...
Thought you mightHooray, found it! I had ehem... for unknown reasons synchronized the lock and unlock methods in the server class.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Nothing up my sleeve ... and ... presto! A tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|