I throw RecordNotFoundException in the lockRecord() only if the thread in waiting state gets interrupted:
Now, I also check that the record number is a valid positive integer, and if not I throw IllegalArgumentException, but I guess it could also be valid to throw RecordNotFoundException.
Now, another possible use that I did not implement, is to check that the record number actually exists in the data file. That is, if the record number is equal to or smaller than the number of records in the database. If not, throw RecordNotFoundException.
In my case I did not implemented this. The lock manager could lock a record that does not even exist in the data file. Now that I think it over, maybe I should work on this. [ October 22, 2006: Message edited by: Edwin Dalorzo ]
Joined: Dec 09, 2000
I certainly don't want to tell you how to interpret the spec, since it is a personal choice and part of the assigment.
But, I would suggest that you should think about the perspective from an interface point of view, rather than an implementaiton point of view.
That is to say, what does (what should) "Record Not Found" mean to someone who is trying to use the lock method on a record?
Cetainly an exception means that something has gone awry.
Joined: Jan 23, 2006
Thank you both.
I have taken it as:
Also check if the recordnumber is still existing and being undeleted in the physical datafile.
RecordNotFoundException is thrown not only in the lock() method. (for e.g., readRecord method also throws it.) So I think, when you are locking a record, if the record doesn't exist in the database, the exception is thrown. This is a multi-user system (in the networked mode), so someone else may have deleted the record when you're about to lock it; then, you throw RecordNotFoundException without even trying to lock the record that doesn't exist. If a thread can't lock an "existing" record because another thread has locked it, the thread just waits until the lock-holder release the lock (intead of throwing RecordNotFoundException).
In my lock method (I have a seperate class for Lock Management) lock the record first, then i call the read method which throws a RecordNotFoundException if the EOF is encountered or if the record has been deleted. If an exception is thrown from the read method I unlockit right away.
In other words, get a lock regardless of the record number. The lockmanager will wait() if the record that is to be locked is currenlty locked and wil return a lock cookie. Then i read the record (via read method) if the read method throws RNFE (for either not found or deleted), i remove the lock on the record.
This technique will handle if the record that you are trying to access has been deleted while you are trying to act on it.
Does anyone see any problems with this implementation?