aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: createRecord(String [ ]) in URLyBird Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: createRecord(String [ ]) in URLyBird" Watch "NX: createRecord(String [ ]) in URLyBird" New topic
Author

NX: createRecord(String [ ]) in URLyBird

Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi all,
In the createRecord() method that is provided for us, I am inserting records only if all seven fields i.e. Name, Location, Size, Smoking, Rate, Date, Owner too are NOT NULL. I'm checking this in the adapter class, so if any value is NOT NULL, am throwing an exception in the adapter class itself. Is it ok?
Or I'm thinking alternatively as: Though the owner field is not specified, will create the record, only in case he specifies the rest of six fields.
The second one makes more sense. Any comments?
Thanks.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Satish,
If one were following simplicity as a guiding principle of the exam, then the following quote from the assignment instructions:

// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String [] data) throws DuplicateKeyException;

might lead one to conclude that no checking (beyond that required for the DuplicateKeyException) is required. I did no checking of the String[] argument to the create method in my own project. I think I can justify this by saying it wasn't required by the project. Beyond that I can think of circumstances in which I might want to create the following record: {"Thompson Builders", "Madison", "Drywall, Painting", null, null, null}
For some reason, I don't yet know what size or rate applies to this new contractor. Presumably I will be able to get this information from the contractor later (and I could use an update when this happens). I will never know the owner when a new record is added to the database because the owner field will remain unassigned until the record is booked.
So, I don't think you need to worry about this, but if you still think you do then I think your second alternative is much better than the first because it treats the owner field properly.
[ February 29, 2004: Message edited by: George Marinkovich ]

Regards, George
SCJP, SCJD, SCWCD, SCBCD
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hey George, good point. Yeah, maybe when a new record is created, he may not know all the values and so he wishes to update it later or leave it. We don't know. I will do that George. I will go with the second option and also allow him to enter null values in other fields. That makes sense too. If we want to make things a bit complex, we can put constraint on the name/location atleast, right. I mean without knowing the name/location he don't want to create any record, right He can leave other fields like smoking, rate, date and others if not known.
Thanks George.
George as you got "the" perfect score I am just curious to know. Can you answer a couple of questions?
1. Which lock mechanism did you use: Record Locking(static lockedRecoords)/RAF synchronization?(Mine is Record Locking)
2. Did you expose the locking to client(as Andrew did) or not(as Phil's choice)? Personally I do not want(as a matter of fact, did not) to expose any locking to the client. All I want to provide to the client is the two business requirements, search and book. That's it. Any comments on this?
The last one is, its not a question, but can you comment on it? What I want to do is as I'm not providing client side locking, when two clients tries to book the same room, I will allow the first thread which reaches to book and for the second one, I want to throw a message that the record was just booked. Its OK right. What do you say?
Thanks George.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Satish,
Originally posted by Satish Avadhanam:
1. Which lock mechanism did you use: Record Locking(static lockedRecoords)/RAF synchronization?(Mine is Record Locking)
My locking mechanism was extremely simplistic. I made no claims that the application as designed is highly concurrent (it isn't, but that's not a requirement specified in the assignment instructions), only that the solution is thread-safe and easily understandable. I'll paraphrase the relevant sections of my design document at the end of this post.

2. Did you expose the locking to client(as Andrew did) or not(as Phil's choice)? Personally I do not want(as a matter of fact, did not) to expose any locking to the client. All I want to provide to the client is the two business requirements, search and book. That's it. Any comments on this?

I did expose locking to the client, so my application follows the traditional two-tier client server model. The main reason I did this was a statement in the assignment instructions:

The main architecture of the application must be a traditional client-server system. There are three key parts: the server-side data management system, the client-side GUI, and the network connection between the two.

I think either two-tier or three-tier implementations can be successful, and I understand the three-tier model has much to recommend it. Moreover, I believe the three-tier implementation is probably a better solution than the two-tier. However, in my opinion what is required for the exam is a reasonable solution that is well implemented. In other words, I don't think candidates who choose a three-tier approach have an advantage over candidates who choose a two-tier approach even though the three-tier approach may be technically superior. Absolutely nothing in the assignment instructions suggests that the approach should be three-tier rather than two-tier. I'm suggesting that you worry less about picking the "best" solution and pick a "good" solution and spend your time making sure your "good" solution is as well implemented as you're capable of making it. A well implemented "good" solution trumps an imperfectly implemented "best" solution in my estimation (this is probably true in real life as well, but I think it's definitely true for the exam). So pick a reasonable solution that appeals to your sensibility and then try to avoid second-guessing your decision and concentrate instead on creating the perfect implementation of your solution. It is probably the case that a simple reasonable ("good") solution is easier to implement perfectly than a complex sophisticated ("best") solution.

The last one is, its not a question, but can you comment on it? What I want to do is as I'm not providing client side locking, when two clients tries to book the same room, I will allow the first thread which reaches to book and for the second one, I want to throw a message that the record was just booked. Its OK right. What do you say?

It seems to me that there are three cases:
1) the record is unbooked, a client tries to book the record, the record is booked for that client,
2) the record is already booked, a client tries to book the record, booking is prohibited for an already booked record, so an exception is thrown and the client is notified of the violation.
3) the record is already booked, a client tries to book the record, the record is booked for that client (overwriting the booking of the previous owner of the record).
I think the assignment instructions require that you implement case 1. I think the assignment instructions permit you to implement either 2 or 3 (as they are mutually exclusive). How to choose whether to implement 2 or 3? Which of 2 or 3 is easier to implement?
By the way, I chose to implement case 3. I believe case 3 is only acceptable if the client knows that the record is already booked. That is, if you allow a client to book a record that has already been booked, it is imperative that you let the user know that the record was already booked. So, for example, it is unacceptable to let a client book a stale record, that is a record that appears (in the JTable) to be unbooked but in reality has already been booked by another client. It is perfectly acceptable to allow a client to book a record that is already booked as long as the client knows the record is already booked. This stale record problem is the reason that I required a lock, read, update, unlock sequence in my book operation.

Locking Approach
I implement locking in the Data class itself by using a Vector of record
numbers to indicate which records are locked...
All the public methods (except for lock, unlock, and isLocked) of the Data class that access the database file are synchronized so that attempts at concurrent access of the database file are sequentialized. All code accessing the Vector of locked records is synchronized on the Vector to sequentialize concurrent access attempts of clients calling the lock, unlock, or isLocked methods.
To ensure thread safe behavior of the database operations it is necessary to follow a lock/database_operation/unlock protocol, where database_operation is any of the database operations such as read and update...
...Adhering to the lock/database_operation/unlock protocol results in a guarantee that only the client who obtains the lock on a record, may unlock that record. This locking scheme provides consistent concurrent access to the data in a multiple client environment.
While locking is only necessary when the database is in remote mode and can be accessed in a multiple client environment because of RMI, it is implemented so that it will also work correctly when the database is in local mode and is accessed by only one user.
Database operations performed in a locked context are thread safe meaning
that dirty reads and dirty writes are not possible. Some database
operations may be performed outside the locked context to achieve better
performance due to less waiting. For example,...
In network mode if the client application were to die for whatever reason
after the client had obtained a lock and before it was able to call unlock,
then that record would remain locked until the server was shutdown and
restarted. The code does not currently handle this sort of client death
situation. This should be handled in the final production system, but I
decided not to implement it now since I believe it is out of the scope of
the assignment...
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi George,

Originally posted by George Marinkovich:
Hi Satish,
I think either two-tier or three-tier implementations can be successful, and I understand the three-tier model has much to recommend it. Moreover, I believe the three-tier implementation is probably a better solution than the two-tier. However, in my opinion what is required for the exam is a reasonable solution that is well implemented. In other words, I don't think candidates who choose a three-tier approach have an advantage over candidates who choose a two-tier approach even though the three-tier approach may be technically superior. Absolutely nothing in the assignment instructions suggests that the approach should be three-tier rather than two-tier. I'm suggesting that you worry less about picking the "best" solution and pick a "good" solution and spend your time making sure your "good" solution is as well implemented as you're capable of making it. A well implemented "good" solution trumps an imperfectly implemented "best" solution in my estimation (this is probably true in real life as well, but I think it's definitely true for the exam). So pick a reasonable solution that appeals to your sensibility and then try to avoid second-guessing your decision and concentrate instead on creating the perfect implementation of your solution. It is probably the case that a simple reasonable ("good") solution is easier to implement perfectly than a complex sophisticated ("best") solution.

Thanks George for a very good advice. Actually what is happening is I read the different posts here and different designs, I'm coming up with new ideas. So the design is constantly changing. The reason why I am not able to stick to a particular design is this is very new to me. I don't have any expereince in any of the issues for SCJD. Its like everything is NEW. If you have observed, I generally ask pretty much asking very dumb quetions too but y'll guys are very very helpful. So as I read posts, you know...I thought am getting better and better and so the design is also getting OK. But as you said, there are quite a huge variety of designs in the ranch and its making me I will try to stick to one. Thanks.

It seems to me that there are three cases:
1) the record is unbooked, a client tries to book the record, the record is booked for that client,
2) the record is already booked, a client tries to book the record, booking is prohibited for an already booked record, so an exception is thrown and the client is notified of the violation.
3) the record is already booked, a client tries to book the record, the record is booked for that client (overwriting the booking of the previous owner of the record).
By the way, I chose to implement case 3.

George, I think I'll stick to 2.

George, Thanks for a very detailed explantion on your "Locking Approach".
I will try to stick with the record locking mechanism I did. It seems its working well. Once I complete the whole assignment, will try to do a full testing using "JUnit" and document the points accordingly.
Thankyou
 
jQuery in Action, 2nd edition
 
subject: NX: createRecord(String [ ]) in URLyBird