This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
My network communication interface just has a modifyRecord() method, and the lock(), update() and unlock() is done on the server. Therefore even if the client crashes the lock will still be released.
My question is, how robust should my lock manager be? I currently don't have any deadlock detection or lock timeouts, because they aren't needed in my design (since I rely on the server-side code being well behaved).
Thats exactly what I did as well, I passed the assigment.
In your design you neatly avoid the problem of client crashes. You only need one servercall per usecase. If you also asume that each client holds at most one lock at the time, you should be able to design your server code, so that deadlocks cannot accur.
hi ranchers good to see someone, who did it on the server side and passed
I also have business on the server side. How did you managed that requirements in "What you must do" section: "Network server functionality for the database system"
I understand that, i must provide two remote interfaces, one for DB layer and other for business.
Peter, how much points did you receive for your design?
Joined: Jul 26, 2006
My full scoring report: General Considerations (maximum = 100): 100 Documentation (maximum = 70): 70 O-O Design (maximum = 30): 30 GUI (maximum = 40): 24 Locking (maximum = 80): 80 Data store (maximum = 40): 40 Network server (maximum = 40): 40
I provided only remote access to the business logic layer, not the database. I understood the requirement "Network server functionality for the database system" broadly. In my understanding it states that the database must be accessible over the network, however it doesn't state that the database must be directly accessible over the network.
You have to read your assignment carefully and notice what it states, but also what it doesn't state.
But always document your design choices, this is a major design choice, and the pros and cons should be discussed in your documentation.
Joined: Jul 03, 2006
Thank you for answer. Gratulation - this is very good score !!!
Originally posted by Peter Jakobsen: But always document your design choices, this is a major design choice, and the pros and cons should be discussed in your documentation.
English is not my primary language, what do you mean by 'pros and cons'?