Dieskun Koper

Ranch Hand
+ Follow
since Aug 15, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dieskun Koper

The Axis stub did not understand that header, so it generated a fault.

Use a client handler to process (and then remove) the header. The handler will do its work before the message gets deserialized, so that will solve the problem.
18 years ago
My create and delete methods were NOPs and I got full score in Network and Datastore, and only lost 1 point in General Considerations. So I do not think you can lose points for that.

I did get 44/80 for Locking, which could be because my locking strategy does not work if records can be deleted or created. But then, many people got 44/80 and nobody knows why.
Hello Peter,

No, I did not. If the record would be removed after the record existence check, while my locking code is running, it will not throw a RecordNotFoundException.
As my delete method is a NOP and my map of records is an unmodifiable (Collections.unmodifiableMap), this should be okay.
If I were to implement the delete method, my locking mechanism won't work. The case you mention is one of several in which it would break.
I did explain this in my choices.txt.
My lock and unlock methods (and not only these methods) check whether the record exists and throw a RecordNotFoundException if it does not, yet I received 44/80.
My locking mechanism would not work if records are created and removed, but my create and delete methods were NOPs (throwing UnsupportedOperationException). I felt I did not need to make a (more complicated) locking mechanism what would work also work in cases my application did not support anyway. I suppose they have something on their checklist saying that the locking should work in all cases and forgot that it would not be logical to do this in cases like mine.
I think you should not expose your lock methods to the client unless your instructions explicitely tell you to.
I used the adapter pattern for my Data class and did not expose any methods of the DBMain interface to my clients, and passed.
I use Java Line Counter to count my LOC. It ignores whitespace and comments. My solution was 2125 LOC.
I've never used JavaNCSS, but what I like about Java Line Counter is that it recursively goes into directories. All I do is drag my src folder onto its desktop shortcut and I get the total LOC of all source files in there.
Hello Reza,

I extended the DBMain interface with another interface with methods that I found were missing, such as another find method. My Data.java class implemented this interface (and so indirectly the DBMain interface).

I don't understand why others are so worried about this design.
There is nothing in the instructions against it, I passed with this solution, and the Java API is full of such solutions:
LayoutManager2 -> LayoutManager
List -> Collection
SortedSet -> Set -> Collection

It's plain O-O.
I did my SCJD in Japan. I ordered it from Sun Japan, they sent an e-mail to Sun US telling them that they got my payment, and the next day I got an e-mail from Sun US with the assignment attached.
So I paid to Sun Japan, and they e-mailed Sun US. I did not need to worry about money transfers.
I hope this information helps you.
Regards,
Dies
I also did not see it as a conflict. The interface has several methods that our client does not need: create, delete, and this find method. I used NOPs for the methods I did not need, and added a find method for the purpose I needed. I got 40/40 for Data store.

In 'real life' we usually do not have access to the database code so we can't add or change any DB methods, so as others suggested an extra filter would be required.
In this case, we have to write the DB code too so we might as well customize it for our needs.

Regards,
Dies
Congratulations!

Too bad you could not spend more time on it.
Many of us in this forum have taken this exam as an opportunity to study fields we have little experience in. It was my first time to build a GUI. This made it, although time consuming, a fun and useful experience.
You got your certification so your boss can be happy, but did you learn anything? Did you enjoy working on the assignment? :roll:
19 years ago
Congratulations, Daniel!
19 years ago
My instructions say the following about the lock method:

'the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked'

Using your method, the current thread gives up the CPU and consumes no CPU cycles until 10 seconds have passed or the record is unlocked.
I would not risk auto-failure here, especially as there are other ways to deal with deadlocks.

And I think it is bad design to throw an unchecked exception for this. Please read up on the difference between runtime and checked exceptions to understand why.
I changed the documentation style of DBMain to javadoc style.
Note that by doing this you are not changing the interface, the .class file would still be the same.


As far as I can see, the update and create method in the DB interface are never used. Do I have to fill the implementation with working code ?



I didn't fill the create and delete methods. Reading other people's posts on the list I feel most people do.


What if the room was already booked by another client inbetween ?
Do I have to display a message to the user, that his selection was already booked while he made his decision ?



There are several solutions to this problem. Pick one that you feel is best and defend it on your choices.txt.

Good luck!
Dies
Right. Note the "in one of these three formats" in the instructions.