Sun just might run a program that calls unlock(40, cookie), and there might only be 39 records in their database.
the method unlock() is a public one, so it does not have to be in a sequence like 'lock - (verify) - modify - unlock'.
RecordNofFoundException to validate than record exist in these methods (only add a line to validate this ).
... in lock method of Data i call read method of database manager (throws RecordNotFoundException), then i call lock method of lock manager (throws SecurityException), so expected exceptions are throws by their respectives managers making my code more clear.
Yes, good point. I have been doubting on that sollution. But then, You need to check from the lock method if the record exists. This can be done in two ways:
1) provide access to DataManager from LockManager. A hassle, to my opinion, and not in correspondence with the idea to separate the functionality of the two classes.
2) (your sollution):
a) From Data.lock: Call LockManager.lock to put the rec in the HashMap. Notice that this method might be caught in a waiting loop when the record was locked already.
b) After LockManager.lock returns, we should check if the rec exists. This is done by calling DataManager.read (from Data.lock)
c) If it appears not to exist, then we should remove the lock again by calling LockManager.unlock, and then raise the RecordNotFoundException.
Your project must conform to this specification. Features that deviate from specification will not receive full credit. You will not receive extra credit points for work beyond the requirements of the specification.
Originally posted by rinke hoekstra:
I found a flaw in my own design.
The question was: Would it be harmful NOT to test for the existence of the record when locking a record?
The answer is yes, there is a possibility that this is harmful.
Consider a thread calling lock on a non-existing record number in a situation where lock doesn't test on existence of records. lets say this is record 42.
Suppose the database has 41 records at the time this happens.
If then, after record 42 (which does not exist) is locked, the create method is called, and this method appends the new record at the end of the database. Then this new record will be... record 42, which is already locked by the other thread. So the new record will immediately be locked by the other thread, and the other thread has control over the new record. This doesn't seem like a wanted situation.
This is possible because the create method does not make use of the locking system, and can create records without locking them first (yes, Ken, that is no problem as long as I don't reuse deleted records, but only append new records).
Originally posted by Ken Boyd:
You can avoid that situation by checking total records in database against pass record number in lock, unlock, update and delete method i.e. -1000 or 1000 record number is not valid if you do something like recordNumber > total_record_available in database.
Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.
Originally posted by rinke hoekstra:
If so, how do you deal with it, as you're not checking on deletions.
[ July 07, 2007: Message edited by: rinke hoekstra ]
You are right, there is no key possible, at least not for urlybird. A record in the database corresponds to a room in a hotel. Why shouldn't a hotel be able to offer more than one room in the urlybird application? It is even very likely that each hotel has various rooms in the offering. So the combination of name/location can for sure not be the primary key. And I cannot think of any other possible combination of keys which could reasonably be a primary key.