I'm currently implementing my Data class for URLyBird 1.2.1. There will be a single instance of the Data class that all clients will connect to via RMI. To promote extensibility and make it easier for other (junior?) programmers to maintain my code I have implemented the Data class using the Facade design pattern, with each method that must be implemented delegating appropriately to either a DBFileAccess class or a LockManager class (i.e. create(), update() etc to DBFileAccess and lock(), unlock() to LockManager.
The DBFileAccess class completely encapsulates the DB file access and has no connection to the logical record locking - exactly what we are after. However, the problem I have is that the lock() method of my LockManager class must check (within a synchronized block) if a record has been deleted while the current thread has been waiting for the lock.
Currently I have decided to pass the instance of DBFileAccess into the LockManager class so that I can call isDeletedRec() within the synchronized lock() method, but this means my LockManager knows about the DatabaseFileAccess class, which kind of defeats the objective of having two seperate classes with only one responsibility each.
Can anyone offer any suggestions of how I could overcome this problem (and I can't move the delete check to the calling class as I would exit the synchronized block), OR do you think that the LockManager lock() method making one call to the DB class is acceptable (and it's not a big deal that the LockManager is reliant on a method within the DBFileAccess class)?
Hello Daniel, your design seems good. Only one suggestion: Isolate completely lockmanager implementation from data.
In your case my position would be: DBFileAccess: CRUD operations over both, deleted and not-deleted records. LockManager: Locking methods in order to ensure logical consistency of abstract indexed entities (records in your implementation) Data: Makes use of these, and implements the specified interface. Here is were I would verify record existence:
SCJP, OCMJD, OCMJEA
Joined: Jul 15, 2006
Many thanks for your feedback and excellent suggestion. I guess I missed the fact that I could do the test for a deleted record in my facade Data class. And as you said, it definitely makes sense to cleanly seperate the DB access and locking responsibility - when I was calling the DB in my LockManager alarm bells started ringing!!
I have the same problem as Daniel (but in a B&S assignment).
I am not sure if I understood orcio's answer correctly. I didnt understand why she unlock in a lockrecord call. After reading the post, this is what I did in my lock method in Data class (facade). Is that what he/she meant or is it appropriate?
I have a problem regarding throwing RecordNotFoundException. My Data class is a facade, just like yours, and I use two other classes DataAccessManager and LockingManager for the actual work. I'm not sure if RecordNotFoundException should be thrown by the DataAccessManager object and allowed by Data to propagate on the stack, or if Data should do something like this:
I like this approach more, but I'm not sure if this design doesn't contradict the idea behind facade pattern.
Any suggestions are welcomed
Don't wake up zombie threads! It has been more than 2 years since this thread was active. The last poster in this thread posted his last message more than 1 year ago, the original poster posted his last contribution more than 2 years ago.
Just start a new thread with your problem/question and other ranchers (like me) will be glad to help you.