aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Fair assumption on locking and avoiding singletons Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Fair assumption on locking and avoiding singletons" Watch "Fair assumption on locking and avoiding singletons" New topic
Author

Fair assumption on locking and avoiding singletons

Chris Zaremba
Ranch Hand

Joined: Nov 22, 2010
Posts: 54

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:




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.


SCJA, OCPJP, OCMJD
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2247

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.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Chris Zaremba
Ranch Hand

Joined: Nov 22, 2010
Posts: 54

Thanks Roberto. I've reviewed my code and the assignment details and what you're saying makes sense.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Fair assumption on locking and avoiding singletons
 
Similar Threads
URLyBird interface?
Should lock methods be callable by the client
Additional runtime exceptions in DB interface
URLyBird-1.2.2 assignment, what should inside the assignment jar?
NX: Exception handling implementing the DBAccess