This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Misc URLyBird questions not covered in the assignment instructions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Misc URLyBird questions not covered in the assignment instructions" Watch "Misc URLyBird questions not covered in the assignment instructions" New topic
Author

Misc URLyBird questions not covered in the assignment instructions

Guillaume Jeudy
Greenhorn

Joined: Jul 27, 2009
Posts: 24
Hi guys,

I'm at a point where most of the requirement specified functionality is implemented for URLyBird 1.3.1 assignment. I'm thinking whether I missed a few important points or not.

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.

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?

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.

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)

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.

6. Automatically have the networked GUI recover from a lost server connection.

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() ?

That's all the questions I had, I would like to hear your feedback on those. I know I could probably not implement anything mentioned above and probably still pass but might lose some points in general consideration?

Take care!
-Guillaume


SCJP 1.4 and 6.0, SCJD
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2564
    
    9

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.

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.

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?

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:
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.

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)

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.

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.

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)

Guillaume Jeudy wrote:
6. Automatically have the networked GUI recover from a lost server connection.

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.

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() ?

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.


Do remember to document all your design choices in the choices.txt file. Good luck.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5 OCPBCD5
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

Howdy, Guillaume!

Question 1: very well observed. You may want to perform some validation to verify if, for instance, record 1 being displayed to user 1 is still the same as the one on the remote server. One thing that you will have to do anyway is verify if the customer ID field of a particular record is still empty before updating it, otherwise client A may end up overriding changes performed by other clients. In my case, I didn't implement a validation on the other fields, because your scenario implies that the application can create and delete records, which we don't have to implement. This is something that you may or may not do, but since this is a possible scenario in real life, you may include your decision in your choices.txt file.

Question 2. ComboBoxes Vs. Text Fields. This is a long discussion... I myself used JTextField for both Name and Location fields.

Question 3. In my case, when the client tries to exit the application, I display a confirmation dialog, asking if the user really wants to quit.

Question 4. I myself allowed the client to book any record, even when the date is in the past. You may want to consider implementing some sort of Policy (or Strategy) that allows the user to book records whose dates are in the past or not.

Question 5. Hum... I'd go with the first option, that is, always display a config dialog before starting the application, in any mode. That's what I did.

Question 6. Hum... I don't think that's required. In my case, if the server becomes unavailable when running the application in client mode, when the user tries to perform any operation, then I simply display a dialog saying that the server is unavailable.

Question 7. When your application is running, there will be no other applications using the database. So no need to worry about other applications using it at the same time.

You are about to submit your project, right? Good luck and if you need anything, please count on us!


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Guillaume Jeudy
Greenhorn

Joined: Jul 27, 2009
Posts: 24
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.

Guillaume Jeudy
Greenhorn

Joined: Jul 27, 2009
Posts: 24
@Roberto,

Thanks for your input! Question 1 and Question 7 occurred to me because of the following instructions:

The company's IT department has a data file that contains the essential information for the company, but because the data must continue to be manipulated for reports using another custom-written application, the new system must reimplement the database code from scratch without altering the data file format.

My interpretation of this, is another application might be reading/updating the same database file, potentially concurrently. Do you think that is correct interpretation? 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? I guess I could overlook this since it is a reporting app anyways which means it would not update any data, it would just read it.

I'm not ready just yet to submit the assignment. I need to implement an online help system and complete the all-around documentation including choices.txt...

Regards,
Guillaume
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2564
    
    9

Ah I think you misunderstood my room point. From my choices.txt I stated:
* 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


This also goes for Q4. Everyone record is a "room" per se. And that makes a room has name, location, size, cost, date customer id fields.

I didn't implement the observer pattern. The way I got those search combo box updated is calling a method in the service layer. I use a search dialog for the GUI. When the search button is clicked, it calls the service layer to populate the combo boxes "everytime".

For RMI implementations, the instructions clearly stated under the Overall Architecture section:
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)


For the server shutdown, I actually have a client count for my networked mode. I used that as my server keep alive. When the server shutdowns, I set a flag and send to clients that server is about to shut down and no searching or booking or whatever can be done. And when the server is down, client must be restarted to continue working. I have tried not restarting client but get RemoteException cos the previous established connection is lost.
Guillaume Jeudy
Greenhorn

Joined: Jul 27, 2009
Posts: 24
@Ktsang

concerning the room point, it is confusing, I understand your thinking that it makes sense to have the same price for the same room size for the same hotel/same city. However, I still think you cannot use this as a unique key for a database record because it means you cannot book the same hotel room for different dates (which would result in several records with the same hotel name/city/size).

In my opinion the data model Sun gave us is pretty bad, I would have put the date and customer id in a separate table with a room number foreign key to the main room table.. Anyways I guess they wanted to keep this simple.

For the RMI port, I think the instructions simply state that you should not run RMI over HTTP transport (using an http server) it has nothing to do with not using port 80. Even though that port is the standard HTTP port, its technically possible but not recommended to run the server RMI with the native JRMP protocol on port 80 (as long as there is not an http server incidently running on the same machine).
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

Howdy, Guillaume!

So champ, when you run your application, it will be the only one using the database file. It's just that I don't have the assignment here with me right now, but I remember that there's a line that says that we don't have to worry about this scenario.

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?


Hum... no. No need to worry about this scenario as well.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Misc URLyBird questions not covered in the assignment instructions