I have implemented the WeakHashMap solution and have built locking around this. I sychronized on the WeakHashMap called lockedRecords. I also have a one instance of the Data class per client. However, the server only has one thread, it doesn't spawn threads per client. My question is, can the locking be valid if there is only one thread?
I think we will need an answer to Liang's question before going too much further with your question.
If you are using RMI, then RMI itself will allocate threads from a pool, and you have no control over which thread will be used for any remote call. Hence the need for an instance of the Data class per client that can then act as the key in your WeakHashMap.
If you are developing a Sockets solution, you should create new threads yourself for each connected client. Since you are controlling the creation of threads yourself, you have the choice of using either the thread or the instance of the Data class as the key in your WeakHashMap (actually, since you can use the thread as the key, you don't really need multiple instances of the Data class).
One more thing for you to think about: just having a WeakHashMap does not solve the orphaned client issue completely. There is the potential that client 'A' locks record 5, client 'B' attempts to lock record 5 and goes into wait state, then client 'A' crashes. In this case, after a certain amount of time the lock indicator will be removed from the WeakHashMap, but client 'B' will not be notified. There is a simple solution, but I will let you think about it for a bit first ...
Hi Andrew, Thanks for that explanation. Unfortunately, I'm using the debugging in Eclipse and only one thread shows up in the server no matter how many clients. So this is misleading.
I am aware of this limitation with the disconnected cliend but because of the exam notes...
"The requirements for this assignment don�t require you deal with client crashes, or other abnormal termination issues. That is, they don�t require that you deal with timeout of locks."
...I wasn't too worried about it. I thought perhaps a finally block but this would not surfice. Or even to check for changes in the size of the WeakHashMap. A simple solution continues to evade me. Best regards, John
author and jackaroo
Or even to check for changes in the size of the WeakHashMap. A simple solution continues to evade me.
Nearly there. It is not just a change in the size of the WeakHashMap that is important - it is the size of the WeakHashMapcontrasted with what your program believes should be the size of the WeakHashMap.
Just on this topic I am having a related but different problem. What happens if my client is blocking indefinitely on IO? I can take its lock away, but I want to interrupt it. Since I am using RMI I do not know how to identify this thread, however.
I have thought about the Unreferenced and WeakHashMap idea, but from what I understand it takes a long time before unreferenced resources get cleaned up. Waiting for 5 or 10 minutes seems too long for even the most patient GUI user. I read that you could change a parameter when starting up the RMI server to reduce the default period, but I do not believe that I am allowed to specify that parameter. In my specs it doesn't seem to allow it.
So I have a daemon thread that (ideally) will interrupt a thread whose lease on a lock has run out (leasing functionity is OK), and then remove the lock from my locked items collection. At the moment it only does the latter, however. By the way, I was able to use NIO for my IO (I checked with Sun Japan), so it is possible to interrupt a blocking thread.
I am passing in uids to my LockManager so that I know that it is the same client, but I can't use a uid to track down a thread the other way. [Or can I? :roll: ]I am using a fat client, because of the requirement to make available all public methods in Data.java to the client.
I have run out of steam on this one. Not sure what I can do here. Any help greatly appreciated.