This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
RecordNotFoundException should be thrown for the unlock, because record 1 is already deleted.
I handled this situation so that delete unlocks the record and notifies all waiters, but I have started to think if I should change the implementation.
What you think, should there be unlock after delete? I think I can do the new implementation, where the RecordNotFoundException is not thrown from the unlock method if the record is deleted and the lockCookie is correct.
Of course a deleted record should be unlocked, otherwise you end up having a deadlock. For example with this scenario:
client2 will now wait forever...
In my solution there is just 1 method (besides read and find) that throws a RNFE and that's the lock-method. Because if the lock-method has successfully locked a record, another client can't do anything with that record (so it certainly can't be deleted). If some other client can update/delete that record, there is something wrong with the locking mechanism. So I created my own custom interface (extending the required one) and i copied the delete, update and unlock method signatures but without the throws RecordNotFoundException clause. I was very pleased with this smart "work-around".