Originally posted by Nicole Gustavson:
However, my interpretation of these requirements was "if there's no lock on the record, the unlock() method just does nothing instead of throwing a RecordNotLockedException or taking some other action."
Still with you.
The way my client is written, there will never be an unlock() call without a corresponding lock() call. So, the only way unlock() would be called without lock() is in the case of malicious hacking. [...]
You lost me. Four remarks.
First, the javadoc documents the contract the Data class adheres to. You change the contract, so you are right in changing the javadoc and documenting your decision. Be aware though that you are essentially ignoring a requirement, so pay attention to the documentation.
Second, you are only sure that the client has been written in that way if you went through a mathematical proof that this is the case. I would submit that the complexity of the system is such that this proof is impossible. In simple terms, your client may well have bugs.
Third, how you have written the client is irrelevant anyway. Your FBN client is not the only client code for the Data class. You know this, otherwise you would have deleted the add() and delete() methods and one of the constructors on the grounds that you don't use them anyway. Another telltale sign is that the Data class isn't FBN-specific in any way.
The Data class is reusable, as is hopefully the rest of your database server code, and you have no direct control over how it is used. Trusting client code to always play by the book, especially in subtler issues such as proper cleanup in exception handling, is bad practice IMHO.
Fourth, you may experience client crashes or network problems between a lock() and its corresponding unlock() call. Not tracking client identity makes recovery difficult. This is admittedly not very important, because you can easily put up a convincing argument that recovery from such situations is well outside the scope of the assignment.
- Peter
[ January 08, 2003: Message edited by: Peter den Haan ]