I am allowed to use NIO channels for my project, and want to take advantage of that to use interrupt() on a (say) permanently blocking thread.
I can do this easily with a sockets implementation, but I am eager to use RMI. I fear, however, that there is no way to identify a thread coming out of RMI to interrupt it. I can tell with a fair probability that a thread is having problems by the amount of time it takes to do a job after getting a lock on my db, I just don't know how to tell which one it is.
[Correct me if I am wrong, but Unreferenced will only tell me if the Thread has finished its job, or an exception has been thrown that kills? the thread. Sun's documentation on Unreferenced seems to be pretty scratchy.]
Unreferenced will tell you when there are no more references to your class implementing Unreferenced. So if you create a Remote object for each connected client, you will get notification when that client is no longer connected (due to them stopping, or explicitly disconnecting, or network problems, or ...).
Unreferenced will not tell you when a thread has completed working.
When a client calls a remote method, the thread it uses to start the remote method will be used for that entire method. So it would be possible to track the thread / method / client at the start of the remote method, and remove your reference at the end of the method.
Note that although the one thread will be used for one method, this does not mean that the same thread will be used by the same client for any other method. Likewise it is possible that some other client may use the same thread after the first client is no longer using it.
Having said all that, I am not sure what circumstances would lead you to interrupt the thread - you mentioned a permanently blocking thread, however I believe this would be out of scope for this assignment.
There is something I just don't get. And it bugs me. I apologise if this topic sounds familiar.
If I have more than one client, then I have serious, serious difficultly making my implementation thread-safe because I cannot stop reads from happening at the same time as writes. Read operations will move the file pointer around all over the place and the recordCount will be increasing unexpectedly at the same time too. [The invariant method I can move to just write operations and avoid it tossing an error for a read operation due to a write operation happening at the same time, so at least this method would be OK.] Ideally, I can use Unreferenced on a Data.java instance created by a client with a frequentish leaseValue (as long as this is not defined on the command line) and then wait for notice that it is not referenced anymore, and then somehow call notifyAll on all the records it was locking to notify any other clients trying to get a lock on records. But as you have said before, I would need multiple clients for that.
OK, the instructions say that I do not need to do locking for read operations. But I take it that it is just referring to using lock and unlock methods to lock a record for the duration of a set of method calls. Surely I still need to stop reads from happening when a write is happening on that record. Yes?
Data.java has synchronised methods for eg. find. Now because I have a fat client with all the public methods from Data.java, I just got to make that find method accessible to the client directly. But if I do that we got say two or three clients accessing find method at the same time, possibly at the same time as write operations. I can synchronise easily if there is only one client locking on Data.java itself via synchronised read methods. But how is that possible otherwise without going spastic and locking the whole database (since find reads every record in the database). :roll:
author and jackaroo
Sorry, about to run away for over a week on holidays (to your part of the world actually - heading into Japan (for Golden Week - I must be crazy :roll: )), so I will keep this short.
From memory I modified my Data class - instead of having the methods of Data class synchronized, I synchronized on a static RAF. I explained why I did it in my choices document, and did not get penalised for that.
Alternatively, have you considered that the instructions dont require you to handle crashed / lost clients. (I know - as professionals, it is almost a requirement in day to day life, but for the certification you dont have to have it.)
Joined: Jun 28, 2004
Thanks for that. I appreciate it.
You say that you are coming to Japan for Golden Week. Yes, you are crazy. But it should work out OK, as long as you don't try to move. At all.
subject: FBNS: Should I give up on the idea of interrupting a thread blocking on IO?