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.
Thank you for making this information available in this forum. While I did not post many topics, it was helpful to see information from past discussions. Although, watch out for getting too involved in the project. Some people focus heavily on the locking issue and identifying clients. I did not implement a locking system that identified the clients. I received all my points for every section except the GUI. So I assume that my database locking mechanism was sufficient. I'm puzzled somewhat about the points I missed on the GUI; however, I do not worry too much since I focus mainly on J2EE technology at my job. Thanks again to all the developers, bartenders, and ranch hands.
General Considerations: Maximum=58 Deductions=0 Actual=58 Documentation: Maximum=20 Deductions=0 Actual=20 GUI: Maximum=24 Deductions=13 Actual=11 Server: Maximum=53 Deductions=0 Actual=53 Total: Maximum=155 Deductions=13 Certification Score=142 Like I said I was shocked on the GUI. I recognize that I'm mainly a J2EE developer, but the 13 point deduction hurts. Oh well at least I did not lose points anywhere else. On the locking mechanism I used a lock class to keep track of the locks. The Lock class used a HashSet as the data structure since I only needed to stored the record number or -1. I did not store any information about a client id. According to the directions we were to create a DataClient class that has all the public methods of the Data class. This includes the unlock, lock, write methods. Since we gave the DataClient access to these methods, I felt we had to assume a good intentioned client to a certain extent. Most people that justify using a client id give the example of a client trying to unlock a record that is currently held by a second client. That is great to be concerned about that issue, but what prevents a malicious client from modifying a record to have bogus information? The fact is that we code the DataClient. So we ensure that a record will be locked, modified, and then unlocked in the appropriate sequence. In my project I tried to follow the "kiss" rule. We were developing an application that could be understood by a junior level developer. Mark, when I saw a previous post by you I realized that I need not worry about more advanced details. You helped convince me to design a simple application with no more than what was in the requirements. No storing of customer's names for booking a flight, etc. Maybe it hurt me on the gui to keep it simple or maybe it was just my lack of Swing exposure. Again thanks to everyone who has contributed to this site.