• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird 1.3.1 Interface does not appear to be sufficient.

 
Lucas Theisen
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The DBMain interface that we "MUST" implement appears to be insufficient. It gives method signatures as follows:

public void update(int recNo, String[] data) throws RecordNotFoundException
public void lock(int recNo) throws RecordNotFoundException
public void unlock(int recNo) throws RecordNotFoundException

Along with the documentation on lock:

Locks a record so that it can only be updated or deleted by this client. If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.

And a supplemental requirement:

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

Adhering to these requirements leads to the following issue. If lock/unlock/update do not return anything and only throw RecordNotFoundException (and RNFE is used as it "should" be), then how do you know if your call was successful? If a client ask for a lock that is already taken, it waits for the lock to be available before completing. However, if a client attempts to unlock or update and does not own the lock, the update will not happen, but there is no sufficient way to notify the client as to what happened. There are 3 ways around this that I can see:

1) Throw a RecordNotFoundException with a message stating "failed to update - not owner of lock".
2) Throw an unchecked exception.
3) Check to see if your update was successful by doing a read and comparing with what you just tried to update to.

All three of these have drawbacks:

1) RNFE has the stated purpose of being thrown when the "record does not exist or is marked as deleted", and the only way to know that this is what really happened would be to catch RNFE and check the message for this type of failure (HUGE HACK).
2) Unchecked exceptions have the stated purpose of "represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way" (http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html) which is clearly not the case here.
3) Seems silly to have to check if your update actually went through by checking to see if the data is what you just tried to set it to.

Am I missing something here? Does anyone else have any ideas? As far as my client implementation goes, i would have the client remember if it was able to obtain the lock (by calling lock and waiting for it to return), but the fact that we have to implement this interface leads me to believe that other applications (such as the reporting applications mentioned in the overview) might need access to the data as specified. Any input/discussion would be greatly appreciated.
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

if a client attempts to unlock or update and does not own the lock, the update will not happen, but there is no sufficient way to notify the client as to what happened.


I throw "IllegalArgumentException" in such case. In fact, for all cases I throw a runtimeException.

You'll find many many threads on this subjet.

Regards,
Alex
 
Lucas Theisen
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alex,

Thanks for the reply. I agree that using RuntimeException (unchecked) is a possible solution. Do you think that is allowable given that Sun's stated purpose for Runtime exception is that it is for programming problems that your application cannot recover from (see the url from my original post). I am just thinking they might call that a bad design (though they really haven't left us any better option. Another thing I was thinking is that we could subclass RecordNotFoundException with something like NotLockOwnerException then it would get through. I dont think that is any less correct, because if you use a RuntimeException anybody that uses your api would have to know that they are possible and your method signature does not specify. Anyway, I think I agree with this approach more than the other 2 I mentioned previously, just wanted to know if I missed any other options.
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Do you think that is allowable given that Sun's stated purpose for Runtime exception is that it is for programming problems that your application cannot recover from (see the url from my original post).
I am just thinking they might call that a bad design (though they really haven't left us any better option.


Based on many previous discussions and feedback from others, SUN will not judge you on this They simply want you to consider the options and make a decision.
In a way, if you don't own the lock and call unlock, IllegalArgumentException makes perfect sense.

Another thing I was thinking is that we could subclass RecordNotFoundException with something like NotLockOwnerException then it would get through.


I personally much prefer the runtime exception than using RecordNotFound for other purposes. But I believe some did it this way.

Regards,
Alex
[ January 16, 2008: Message edited by: Alex Belisle Turcot ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic