In reference to your locking, it sounds as if the lock method is implemented in your Connection object, and it delegates the job of actually performing the lock to the LockManager. So then Data has no code in its lock method, right? I am asking because this was the way I originally implemented it, but I was concerned that the requirements stated that lock and unlock need to be implemented in Data. Did you have that requirement, and if so, did you have the same concern I am having?
However, I thought it would be important to design my server so that it can connect to multiple databases (because the requirements imply that multiple database files might be used, and not just db.db), and that's how I designed it. Essentially, for every client, the server creates a remote object that wraps the reference to a database file and the corresponding lock manager. So, if there are 5 databases and 50 clients, I have 5 references to database files, 50 remote objects, and 5 lock managers. The remote object (unique to each client) was used as a client id. The lock manager is the class that does the locking and unlocking, and all the code was just 28 lines of code (including record lock/unlock and database lock).
Does that mean you will allow/ask the remote user to enter the database name?
I have implemented lock and unlock method in Data class. My Data class knows LockManager...
Originally posted by Eugene Kononov:
I finally got my results: 150/155
Maximum=58 Deductions=3 Actual=55
Maximum=20 Deductions=1 Actual=19
Maximum=24 Deductions=1 Actual=23
Maximum=53 Deductions=0 Actual=53
Maximum=155 Deductions=5 Certification Score=150
Thanks to all who contributed to all the discussions that helped me. Here are a few things that I'd like to say about the certification.
1. I consider the SCJD certification a very valuable experience. I had to learn a lot of stuff to prepare for it, and I feel that I made a big step forward as a developer during the process, especially in formalizing and much improving my knowledge of Swing, layout managers, event handling, design patterns, and thread programming.
2. It took me about 350 hours from start to finish (including the research) to complete my project, I did quite a bit of refactoring.
3. As you can see, I got the maximum points for the server, but I didn't implement server GUI, graceful shutdown, Unreferenced, unlock(-1), cleaning the stale connections, timeouts, or anything else of that sort. However, I thought it would be important to design my server so that it can connect to multiple databases (because the requirements imply that multiple database files might be used, and not just db.db), and that's how I designed it. Essentially, for every client, the server creates a remote object that wraps the reference to a database file and the corresponding lock manager. So, if there are 5 databases and 50 clients, I have 5 references to database files, 50 remote objects, and 5 lock managers. The remote object (unique to each client) was used as a client id. The lock manager is the class that does the locking and unlocking, and all the code in that class was just 28 lines of code (including record lock/unlock and database lock).
4. I implemented MVC in client, but I had (and still have) a lot of doubts about the best MVC design, especially in the interactions between the views and controllers. I think this is where I lost the 3 points in general considerations.
5. I kept my GUI extremely simple, -- just one JFrame for searching, viewing, and booking. I also had a JDialog for the on-the-fly database switching (local or remote). Not sure where I lost 1 point in GUI, but it might have been because I used the event thread to do the processing (so if connecting to remote database took 5 seconds, the "connect" button stayed pressed for 5 seconds).
6. I didn't use security managers, policy files, codebase parameters, classpath setting, dynamic downloading, or any other things that can complicate your project and the set up. My server and client are started as simple as
java -jar server.jar <port>
java -jar client.jar
No environmental setup of any kind is needed.
7. I think it is extremely important to document your design decisions clearly and in detail in your design choices document. If I were the grader, I would prefer an inferior design with a superior documentation to a superior design with an inferior documentation. My design choices document was about 7 pages long and covered 12 topics: Abstract, General Considerations, RMI vs. Serialized Objects Over Socket Connections, Modifying vs. Extending the Data class, Server Design, Database Record Locking, Simplifying Data Access, Client design, Exception Handling, Record Search Algorithm, Connecting the Classes Together -- a Flight Booking Example, User Interface.
8. I think one of the complex (and important) things for the successful completion of the assignment is to differentiate between the extras that are not in the requirements from the extras that are implied by the requirements. For example, as I mentioned above, a lot of people are spending much time with server GUI, security managers, timeouts, and other features that provide absolutely no value to the project extendibility. Yet it is easy to miss the really important issues (not explicit in the requirements) that might cripple the design.
9. Finally, some word of encouragement, -- all the answers to all your questions are right here in this forum.
P.S. While Mark is in Zurich buying the watches in bulk so that he can resell them in Detroit, I decided to take advantage of this by posting the message in this forum, rather then in the Certification Results, because I think this discussion really belongs here.
[ August 01, 2002: Message edited by: Eugene Kononov ]