lock-delete-unlock and RecordNotFoundException

[Jared Chapman]

Consider the method in the DB interface provided by Sun:

public void unlock(int recNo, long lockCookie) throws RecordNotFoundException, SecurityException;  

and the program requirements provided by sun:

long lockCookie = db.lock(recNo);
db.delete(recNo, lockCookie);
db.unlock(recNo, lockCookie);  

My instincts tell me that, in this case, I should interperate this requirement (about when to throw RNFEx) as:

"...should do so if a specified record does not exist, AND go ahead and do so in any other appropriate cases where you are looking for a record (or its representative) and cannot find it, since we didn't explicitly state in the requirements that you MUST ONLY do it if the record does not exist or is marked as deleted."

In the unlock method, I am considering the representative of a record to be its record number. If I attempt to unlock record #5, but record #5 is not locked, then I will not be able to find it among the locked records, and therefore should throw a RecordNotFoundException.

At least this way you can provide the information that an attempt was made to unlock a record that was never locked, and possibly track down a breach of the lock(recNo)- modify(recNo)- unlock(recNo) contract.

Any thoughts?
[ November 02, 2004: Message edited by: Jared Chapman ]

[Kai Witte]

hello,

I am against it.

When someone tries to unlock a record that has not been locked before it is a programming error; it shall not be possible by a misuse of the program by the user. It is always avoidable and should be avoided rather than recovered. Thus the Exception should be a RuntimeException.

I suggest a "LockException extends RuntimeException".

Conan

[Jared Chapman]

Hi, and thanks for your response.

I agree, it is a programming error and should therefore throw a runtime exception, if any. Good point.

RecordNotFoundException is indeed a meaningless exception in the unlock method. After all, unlock doesn't know if it's being called after a create or delete - one is supposed to find a record and one isn't.

So let me make sure I understand your suggestion correctly:

If a user tries to perform a data-altering method, like

delete(recNo, madeUpLongValueWithoutCallingLock)

without locking the record first, one of two things will happen:
1. recNo is in lockedRecords, but the made up long value will not match the long value used to lock the record, and a SecurityException should be thrown.
2. recNo isn't in lockedRecords, meaning the record was never locked (programming error), so a runtime exception should be thrown.

Or, if a user tries to unlock a record without locking it first (using recNo and some made-up value), the same two things can happen, and should be handled the same.

So this LockException you suggest (which is a runtime exception) will be thrown from update, delete, and unlock, if the record isn't locked.

Correct?

[Kai Witte]

hello,

Originally posted by Jared Chapman:

If a user tries to perform a data-altering method, like

delete(recNo, madeUpLongValueWithoutCallingLock)

without locking the record first, one of two things will happen:
1. recNo is in lockedRecords, but the made up long value will not match the long value used to lock the record, and a SecurityException should be thrown.
2. recNo isn't in lockedRecords, meaning the record was never locked (programming error), so a runtime exception should be thrown.

Or, if a user tries to unlock a record without locking it first (using recNo and some made-up value), the same two things can happen, and should be handled the same.

So this LockException you suggest (which is a runtime exception) will be thrown from update, delete, and unlock, if the record isn't locked.

Correct?

I recommend a LockException for all cases you mentioned: Any kind of violation of the "lock contract". Here is a part of my choices.txt in which I described a part of the "lock contract":

-The methods update and delete require a lock, and only those.
-To call a method which requires a lock clients must call the lock
method first and wait for it to return.

(ommited some parts, for example about when unlock must be called)
Using the same kind of RuntimeException for all violations of the lock contract makes it simpler. I find it hard to justify to distinguish between different kinds of lock contract violations by using different exception classes.

I had B & S 2.3.2, which has no cookie, so I didn't think about your concrete case as much as you did, though.

Conan