Fair assumption on locking and avoiding singletons

[Chris Zaremba]

I'm working on the UB assignment (I've not seen a version number anywhere) and have a couple of questions.

The interface I'm given has the following method:

// Deletes a record, making the record number and associated disk storage available for reuse. 
// Throws SecurityException if the record is locked with a cookie other than lockCookie. 
public void delete(int recNo, long lockCookie) throws RecordNotFoundException, SecurityException;

It specifies that the SecurityException should be throw if the record is locked with a cookie other than lockCookie which would imply if it's not locked with any cookie then don't throw it. Do you think it's fair to throw a SecurityException if the reccord is not held by this cookie or by any other cookie. It's the way most people would understand it but I don't want to take any chances. Obviously I would document this in choices.txt. EDIT. Ignore this. I totally failed to notice RecordNotFoundException which can be used for exactly this reason.

My second question is about the use of singletons (maybe that should be singleton instead of singletons ). My design has a DataAccess class (reads/writes to the file). On top of this sits an optional CachedDataAccess class (caches and improves concurrency). This is accessed from the Data class (a facade that brings together the data access and locking manager). I've decided to not make any of these class a singleton but have documented that only a single instance of each class should ever access one particular database file. This allows the application to open more than one database file should the need ever arise in the future. Similar to my previous post the question is if it is acceptable to leave this down to the documentation rather than enforcing it in code. There must be an argument against it otherwise the singleton pattern wouldn't exist.

[Roberto Perillo]

Howdy, Crhis!

Just some small considerations on your first question, the SecurityException should be thrown if the given cookie is different from the one that originally locked the record. If the record is not locked, then you can throw IllegalStateException. You can find more about similar discussions here and here.

About the second question, I'd say that it is ok. As long as you guarantee the integrity of the database being used, then it's ok. If you use only one Data object throughout your code and always synchronize on the same object (case its methods are not synchronized), then you can guarantee it. I just advise you to also document it in the JavaDoc comments of the Data class, saying that it must be used carefully, etc.

[Chris Zaremba]

Thanks Roberto. I've reviewed my code and the assignment details and what you're saying makes sense.