Quick question about an unlocking issue in the UrlyBird assignment 1.1.2.
When I run the following code, say for 1 of the methods, that uses a locking strategy, say update.
When I run the above with a different lockCookie as in the "123L" and I use the following strategy in my code for unlock:
(1) If cache contains record number for passed lockCookie Value, remove the cache entry and signal all the record number can be inserted.
or throw Exception.
My problem above is if 1 runs the above code for 2 or more clients, the first client has locked recNo, above is 20, but never releases it in the unlock method, because the latter method never got passed the correct lockCookie.
Just wondering how people approached this issue?
Mark O' Sullivan wrote:My problem above is if 1 runs the above code for 2 or more clients, the first client has locked recNo, above is 20, but never releases it in the unlock method, because the latter method never got passed the correct lockCookie.
Well, I'd say that you don't have to worry with this situation. The thing is, we have an API, and we have to use it correctly so that things happen correctly. When you call the lock() method, you receive a number that you will use to call the update() and unlock() methods. When calling these methods, the value you first received is expected to be passed to these methods. So, if you do everything correctly, no problems should occur. Another thing, you are considering that the record is locked forever, right... but in this case you would be using the API wrongly. You don't really have to create some sort of timeout mechanism; you would be over complicating things. Just expect the users to use the API correctly and everything will be fine!
Carlos Morillo wrote:I do what my interface says.
Alright! That's the spirit!
Like Roberto already mentioned: such a situation should never occur in your code, so you don't have to deal with it. If you encounter such a problem in your code, it means you have coded a bug and this situation should be discovered during testing.
But you should "protect" your Data class against wrong usage. For example: when someone calls the read-method before the init-method is called (this method initialises my record cache, calling read without the cache would be useless) I throw an IllegalStateException with a specific message. When you try to update a record without owning the lock on that record an IllegalStateException is also thrown with another message, clearly indicating you have to lock the record prior to updating. If you pass a null-value to my find-method an IllegalArgumentException is thrown. And so on... None of these exceptions are caught in my program, because if the Data class is used as described, these situations will never occur.
If you (or any other developer) have to make changes to my program (because I left the company) and he doesn't use the Data class as designed (and he didn't read the extensive javadoc comments) he will get a human-readible informative message about how that method should be used or what valid values are for a specific parameter.