SCJP 1.4 and 6.0, SCJD
Guillaume Jeudy wrote:
1. Locking: I was thinking about a scenario where user 1 would search records. User 2 deletes and recreates a record (i'm reusing deleted record space and also using file position as the record number). User 1 books a record, but now this record has been replaced by a completely different record from User2. I don't think I have to handle such a scenario, what do you guys think? I'm thinking some sorts of optimistic locking implementation could prevent that but since I don't have a version timestamp field to validate against I dont want to go into the dirty business of comparing each field to ensure it is the right record being updated. Note, this might work if the customer id is the only editable field but no longer holds if all fields can be modified.
Guillaume Jeudy wrote:
2. Combo boxes for search fields, since the search requires an exact string match it is awkward to use with a regular JTextField. I would rather not use Combobox with suggestions as that would complexify the GUI and also require the GUI to subscribe to back-end changes and automatically update the list of suggestions. Do you think that is a must?
Guillaume Jeudy wrote:
3. Have a confirmation box if the user wants to quit the application. That is not a big deal but again I don't feel like it's needed. I mean some major apps don't have this implemented such as Internet Explorer.
Guillaume Jeudy wrote:
4. Prevent user from booking to a room with a date in the past? All entries are in the past, the latest ones are from 2005. If I implement this I force the Sun examiner to change his system clock in order to use the app. How have others tackled this ? I have not implemented the 48hrs rule since that doesn't seem like a hard set requirement and is subject to change in the real world. (at least that's my interpretation and the last thing I would want is the system limiting me in my booking options)
Guillaume Jeudy wrote:
5. Don't display the options dialog box at standalone GUI client startup if options saved in properties file are valid. Give the user the chance to switch database by using the menu option. I don't feel that is required.
Guillaume Jeudy wrote:
6. Automatically have the networked GUI recover from a lost server connection.
Guillaume Jeudy wrote:
7. Locking: I use a thin client and only expose service-level methods to the client such as book(), find() that handles locking properly. It is not clear whether some other application would use DBMain interface directly. If thats the case then should I guard against a misbehaved client calling lock() and never calling unlock() ?
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Guillaume Jeudy wrote:
K. Tsang wrote:OK nice to hear you are almost done
Here is my thoughts on your situations.
Guillaume Jeudy wrote:
1. Locking: I was thinking about a scenario where user 1 would search records. User 2 deletes and recreates a record (i'm reusing deleted record space and also using file position as the record number). User 1 books a record, but now this record has been replaced by a completely different record from User2. I don't think I have to handle such a scenario, what do you guys think? I'm thinking some sorts of optimistic locking implementation could prevent that but since I don't have a version timestamp field to validate against I dont want to go into the dirty business of comparing each field to ensure it is the right record being updated. Note, this might work if the customer id is the only editable field but no longer holds if all fields can be modified.
K. Tsang wrote:
This situation really depends on the timing. Yet in my UB, I do check if the record being booked is indeed the record the client intend to book using the equals and hashcode methods. How? I assume you have some class call Room then add the equals/hashcode method checking the record number (the primary key of the file) with the hotel name and city name and the number of people allowed. Of course you really need to know what makes each record unique.
What you are talking about here is the business key which should not be editable in my mind. However I don't see how you can make a record unique because you could still have several rooms with the same hotel, same city with same number of people allowed. I don't see that check viable unless we had something like the room number which would identify uniquely the room without a doubt.
Guillaume Jeudy wrote:
2. Combo boxes for search fields, since the search requires an exact string match it is awkward to use with a regular JTextField. I would rather not use Combobox with suggestions as that would complexify the GUI and also require the GUI to subscribe to back-end changes and automatically update the list of suggestions. Do you think that is a must?
K. Tsang wrote:
I used combo boxes. Yet text fields are also fine but do take care of capitalization and lower case for user input. For example if the user enters "hilton" for hotel name but the file only able to match "Hilton" then you manually need to capitalize the first letter. Then now what happens if they enter "34dkd" or some weird text? Using combo box guarantees the case matching. As for when new hotels added, the new items must be retrieved before that combo box is displayed for searching.
Guillaume Jeudy wrote:
Did you implement an observer pattern with all connected clients automatically updated when the server changed the database file?
Guillaume Jeudy wrote:
3. Have a confirmation box if the user wants to quit the application. That is not a big deal but again I don't feel like it's needed. I mean some major apps don't have this implemented such as Internet Explorer.
K. Tsang wrote:Don't bother
Guillaume Jeudy wrote:
4. Prevent user from booking to a room with a date in the past? All entries are in the past, the latest ones are from 2005. If I implement this I force the Sun examiner to change his system clock in order to use the app. How have others tackled this ? I have not implemented the 48hrs rule since that doesn't seem like a hard set requirement and is subject to change in the real world. (at least that's my interpretation and the last thing I would want is the system limiting me in my booking options)
K. Tsang wrote:OK if your book dialog does not allow user to change the dates then no need to worry. In my book window, I actually allow users to set the checkout date. Meaning I implemented the 48h thing by getting today's date plus 2 days and set that to the book window as default. I use combo boxes for month, day, and year. Do all the checking and stuff seems alot of work, especially also checking for leap year and stuff... thats why they are dates.
Ok so it means you ignore the date field from the database file? I thought a record in the database file represented a room booking and not a room per se. In other words you could have several records for the same room but a different booking date. That makes me think of other things such as data validation. In the DBMain#create() implementation do you allow a user to create a record for the same hotel name, city, size, date? I mean there is no way to tell it is the same room so I guess we should allow creation in this case as well.
Guillaume Jeudy wrote:
5. Don't display the options dialog box at standalone GUI client startup if options saved in properties file are valid. Give the user the chance to switch database by using the menu option. I don't feel that is required.
K. Tsang wrote:The properties file should only be saved if and only if all fields are correct. For local mode, database path is correct, file must match cookie value, have read and write permission. Similarly, for remote mode, add the port checking (eg >1024 to avoid being a web server - one of the RMI restrictions)
port should be higher than 1024? I haven't seen anything about this in RMI specifications. I validate if its between 1 and 65535. If the port is already taken
the server won't start anyways (it will exit with an error message).
Guillaume Jeudy wrote:
6. Automatically have the networked GUI recover from a lost server connection.
K. Tsang wrote:
Don't bother, once the server is shut down the GUI should pop up an error saying the server is down and the client must also be shutdown. Cos without the server, you can't book, search or anything. Now do you want to implement a server shutdown hook to detect the server availability? Not a must.
I still thought it would be nice for clients to recover, if for example the server binaries are updated and the server restarted it would be nice that clients wouldnt have to restart as well.
Guillaume Jeudy wrote:
7. Locking: I use a thin client and only expose service-level methods to the client such as book(), find() that handles locking properly. It is not clear whether some other application would use DBMain interface directly. If thats the case then should I guard against a misbehaved client calling lock() and never calling unlock() ?
K. Tsang wrote:Use using a service layer right? Then keep that design. Exposing lock and unlock to the client directly would ultimately change your design, which you wouldn't want at your stage.
Yes I use a service layer, the only worry I have is the assignment instructions hint at the fact that another custom reporting application might use our DBMain implementation directly. I wanted to know if others have implemented timer tasks that would cleanup long standing locks to guard against misbehaved clients...
K. Tsang wrote:
Do remember to document all your design choices in the choices.txt file. Good luck.
Thanks, I appreciate your fast reply on this.
SCJP 1.4 and 6.0, SCJD
SCJP 1.4 and 6.0, SCJD
* Uses name, location, and size combination to check for equality because there is no room floor or room number provided
* For example, the Hilton Hotel in New York has a room for 1 person costing $150; this same hotel can not have another room for 1 person costing $100
Network Communication Approach
You have a choice regarding the network connection protocol. You must use either serialized objects over a simple socket connection, or RMI. Both options are equally acceptable. Keep in mind that networking must be entirely bypassed in the non-networked mode.
Restrictions on RMI
To avoid unnecessary complexity in the marking environment certain restrictions are placed on solutions that use RMI. Specifically:
* You must not require the use of an HTTP server. (CAN NOT BE PORT 80)
* You must not require the installation of a security manager.
* You must provide all classes pre-installed so that no dynamic class downloading occurs.
* You must use RMI over JRMP (do not use IIOP)
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
SCJP 1.4 and 6.0, SCJD
We also implement create and delete functionality in DBMain even though UB app doesn't use it. Wouldn't that hint at the fact this reporting application re-uses our database code?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
When evil is afoot and you don't have any arms you gotta be hip and do the legwork, but always kick some ... tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|