I read a lot about the second level of locking and "consuming no CPU cycles" in this board. Many topics are discussing if locking on a single record (and only waking up one relevant thread with signal) meets the requirement better than locking on the HashMap (and waking up all threads maybe with signalAll).
I am now at the point in my assignment where I must implement it and I feel that my DBAccess-interface disallow the wait/notify mechanism. The general requirement of the locking strategy of my assignment says:
Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
but the description of e.g my deleteRecord method in the interface says:
Throws SecurityException if the record is locked with a cookie other than lockCookie.
I think that I should give the SecurityException back to the client and handle it there (maybe writing a text to a label "Room is actually locked. Try it again") rather than dispatch the actual thread to the waiting state.
What do you think is the better solution for my requirement?
Mike Semlitsch<br />SCJD (URLyBird in progress...)<br />SCJP<br />LPIC-1
If I understand correctly, you wonder why SUN says your thread should wait until the resource is available, but however says to throw SecurityException from Delete ?
The general idea (at least I think what everyone is doing), you call the "lock" method. Inside that method, if the record (resource) is locked, you wait for it. Once the thread is notified (by any other thread who owns the lock on the record), it will lock the record.
Then, once you locked the record, you call delete. The description of deleteRecord rather means "make sure the executing thread is really the owner of the lock before you execute any delete operation, if it's not, throw SecurityException"
Please tell me if I missed the boat on your question.
Regards, Alex [ December 15, 2007: Message edited by: Alex Belisle Turcot ]
Joined: Sep 30, 2007
thanks for your answer. OK, after your hint and after reading the description of my DBAccess-interface again the thing is clear, I need the wait/notify mechanism. I thought (implied) the lock method throws SecurityException too, when the requested record is locked by another thread just like the methods unlock, deleteRecord... That's maybe because I don't have much spare time to work on the assignment
Then, with the new knowledge, I have a next question. How should I handle client crashes? When a client locks a record and before he can make the unlocking, the network connection abort. Then the record is locked with the cookie of the crashed client. Creating a controller-thread that checks the duration a record is locked with the same cookie and unlocks it when e.g. 1 minute is over, seems not to be the best way.
How can I determine that the client lost the connection? Is there a way with unique remote objects (RMI with a factory) and something like a reference counter on this object? I am not very familiar with RMI but I think if the client lost the connection then RMI realizes it and frees the reference on this object. If I have put this object in an HashMap before then the reference counter should change from 2 to 1. If the reference counter is 1 then the record can be freed by a separate controller-thread.
Is something like this possible or is there a better way?
Regards, [ December 15, 2007: Message edited by: Mike Semlitsch ]
Alex Belisle Turcot
Joined: Apr 26, 2005
Take a look at rmi.server.Unreferenced and also WeakHashMap. A lot of people choose not to handle client crashes.
Joined: Sep 30, 2007
Thank you Alex,
I looked at the api for the Unreferenced interface and the WeakHashMap. They would help me a lot if I want to implement crash-handling.
Do the other pass the exam without handling crashes?