SCJD - 370 out of 400

[Rob Cromley]

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

[Srikkanth Mohanasundaram]

Great work,Can you share your learning experience with us?

[anil kumar]

Congrats Good Score.....

[Joe San]

Congrats!

[Vassili Vladimir]

Congrats

[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!!!

[Mario Beekwilder]

Nice work, you scored 5 points more then me

[Anna Hays]

Great work! Go have a beer.

[Mark Smyth]

Nice score especially on the locking front. Have a well deserved beer or two.

[Ken Boyd]

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
https://coderanch.com/t/189117/java-developer-SCJD/certification/deadlock-pointer-verification

then it will help me a lot.

Thanks,
Ken