aspose file tools*
The moose likes Certification Results and the fly likes SCJD - 370 out of 400 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Certification Results
Bookmark "SCJD - 370 out of 400" Watch "SCJD - 370 out of 400" New topic
Author

SCJD - 370 out of 400

Rob Cromley
Greenhorn

Joined: Aug 30, 2004
Posts: 24
Woohoo!!!

After 5 1/2 weeks of waiting I just got my score:
Possible/Actual
General Con: 100/92
Documentation: 70/65
OOD: 30/30
GUI: 40/33
Locking: 80/80
Data Store: 40/40
Network Server: 40/30
Total: 400/370

Thanks so much for this site (it answered alot of questions I had, and confirmed that I was working correctly on more than one occasion).


SCJP(1.4), SCWCD(1.4), SCBCD(1.3), SCEA(part 1), SCJD
Srikkanth Mohanasundaram
Ranch Hand

Joined: Feb 07, 2007
Posts: 185
Great work,Can you share your learning experience with us?
anil kumar
Ranch Hand

Joined: Feb 23, 2007
Posts: 447
Congrats Good Score.....
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9243
    
    1

Congrats!


SCJP 1.4, SCWCD 1.4 - Hints for you, SCBCD Hints - Demnachst, SCDJWS - Auch Demnachst
Did a rm -R / to find out that I lost my entire Linux installation!
Vassili Vladimir
Ranch Hand

Joined: Mar 08, 2007
Posts: 1585
Congrats


Vassili ...
SCJP 5.0, SCWCD 1.4, SCJA 1.0
Rob Cromley
Greenhorn

Joined: Aug 30, 2004
Posts: 24
Here's how I approached my solution (my project was B&S):

GUI: Basic minimum. I had a JTable with the necessary fields, a dropdown with the cities (, a textbox for name, and a checkbox for fuzzy search on the name. I've worked with Swing in the past and have always had a hard time creating screens that look good no matter what you do to resize them, so I made my screen to not be resizable (I think that's probably why I lost 7 points on my GUI design).

Locking/database: Big picture - I loaded in all the data into memory at once and worked off of that (the database is small). I created a value object over each record of data (in this case, each contractor). Over top of that I created another value object containing the contractor object and any additional data I wanted to manage that was not in the database (record number, lock number, etc.) called DBRecord. I then loaded each of these objects into a set keyed by record number. I used this set for all database access (reading, locking, updating, creating, & deleting). If an object was created, updated, or deleted I rewrote this set to the hard drive behind the scenes. When a request came in to lock a record, I synched on an internal static variable to determine if the record was locked. If already locked I ended the synch and put the thread into wait mode. If not locked I locked the row by getting the next lock number (just a sequential number), assigned it to the DBRecord, and ended the synch. As a record was unlocked I notified all waiting threads that I was done and let them 'have a feeding frenzy' to try to get to the record they were waiting for.

I also used a DAO to handle all interactions with my database server. For example, if I was wanting to update a contractor I would pass the contractor object (the same one described above) to my DAO's contractorUpdate method. The DAO would then do a lock, update, and unlock on my database server.

I created a testing program over these objects. I performed every function individually (read, lock, update, unlock, etc.) to make sure that they worked correctly then did a bulk test where I spawned 100 threads to each try to lock, update, wait a second, then unlock the same record (this forced a delay so threads needed to wait for the record to not be locked anymore). In my case I had each thread try to concatenate an 'X' onto the city name of a particular record. After all the threads ended I looked at the city name and made sure that the 100 X's were there.

Networking: I basically just created an interface over the server. Locally I went through an object using this interface. Remotely the client had an object that used this interface. The client object established a socket connection to the server (yep, I used sockets....I'm old school) and sent a serialized value object to the server. The server upon accepting the connection spawned another thread to process this request. Each of these server threads used the same object I used locally to do any database requests. After the request was done I loaded the value object back up with the results, reserialized it, and sent it back to the client.

I think that's about it. If you guys think of other questions to ask me let me know (I'm in that 'proud pappa' mode so I'm happy to talk about my assignment now).

Thanks for the congrats guys!!!
Mario Beekwilder
Greenhorn

Joined: Apr 20, 2006
Posts: 2
Nice work, you scored 5 points more then me
Anna Hays
Ranch Hand

Joined: Nov 09, 2003
Posts: 131
Great work! Go have a beer.
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
Nice score especially on the locking front. Have a well deserved beer or two.


SCJP<br />SCJD
Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329
Originally posted by Rob Cromley:
Here's how I approached my solution (my project was B&S):

GUI: Basic minimum. I had a JTable with the necessary fields, a dropdown with the cities (, a textbox for name, and a checkbox for fuzzy search on the name. I've worked with Swing in the past and have always had a hard time creating screens that look good no matter what you do to resize them, so I made my screen to not be resizable (I think that's probably why I lost 7 points on my GUI design).

Locking/database: Big picture - I loaded in all the data into memory at once and worked off of that (the database is small). I created a value object over each record of data (in this case, each contractor). Over top of that I created another value object containing the contractor object and any additional data I wanted to manage that was not in the database (record number, lock number, etc.) called DBRecord. I then loaded each of these objects into a set keyed by record number. I used this set for all database access (reading, locking, updating, creating, & deleting). If an object was created, updated, or deleted I rewrote this set to the hard drive behind the scenes. When a request came in to lock a record, I synched on an internal static variable to determine if the record was locked. If already locked I ended the synch and put the thread into wait mode. If not locked I locked the row by getting the next lock number (just a sequential number), assigned it to the DBRecord, and ended the synch. As a record was unlocked I notified all waiting threads that I was done and let them 'have a feeding frenzy' to try to get to the record they were waiting for.

I also used a DAO to handle all interactions with my database server. For example, if I was wanting to update a contractor I would pass the contractor object (the same one described above) to my DAO's contractorUpdate method. The DAO would then do a lock, update, and unlock on my database server.

I created a testing program over these objects. I performed every function individually (read, lock, update, unlock, etc.) to make sure that they worked correctly then did a bulk test where I spawned 100 threads to each try to lock, update, wait a second, then unlock the same record (this forced a delay so threads needed to wait for the record to not be locked anymore). In my case I had each thread try to concatenate an 'X' onto the city name of a particular record. After all the threads ended I looked at the city name and made sure that the 100 X's were there.

Networking: I basically just created an interface over the server. Locally I went through an object using this interface. Remotely the client had an object that used this interface. The client object established a socket connection to the server (yep, I used sockets....I'm old school) and sent a serialized value object to the server. The server upon accepting the connection spawned another thread to process this request. Each of these server threads used the same object I used locally to do any database requests. After the request was done I loaded the value object back up with the results, reserialized it, and sent it back to the client.

I think that's about it. If you guys think of other questions to ask me let me know (I'm in that 'proud pappa' mode so I'm happy to talk about my assignment now).

Thanks for the congrats guys!!!


Great Score on Locking!!!

I have one question for you on locking (if you are still around after many beers..hhaha))

Did your Data class (mine is URLyBird) allow multiple room (hotel booking) booking by one client? I am allowing just one room per client. If tester try to book multiple rooms per client it will go into deadlock. I will also document that via GUI you can only book one record per client request not multiple (which follows into future enhancement and out of scope of current assignment)

If you can comment in following thread
http://www.coderanch.com/t/189117/java-developer-SCJD/certification/deadlock-pointer-verification

then it will help me a lot.

Thanks,
Ken


SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SCJD - 370 out of 400
 
Similar Threads
SCJP 91%, SCJD 370/400, SCWCD 93%, SCBCD 84%
(B&S) I Passed!!!
SCJD 370/400
Passed SCJD - 92%
Passed SCJD with 370/400