Passed with 354 / 400

[Christian Nicoll]

Hello Ranchers,

I took the essay-exam on Friday the 07-18-08 and today I found on the certmanager-site that I've passed with 354 points. In the different sections I've the following points:

General Considerations (maximum = 100): 99
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 31
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40

One of the last user who passed the exam was Chih-Wei Lee. He reached exactly the same points in the same sections as I do. I find this interesting, so perhaps we 've made similar applications (and failures).

I read nearly all chapters from Andrews Book. I started with the assignment in april 2008.

I loosed most of my points in the locking-section. I was informed about the mystery 44/80-score and so I spent a lot of time with testing and refusing my locking-approach. Sadly without succes.

A very helpfully thread is in my eyes the one of Ken Krebs.
https://coderanch.com/t/184523/java-developer-SCJD/certification/NX-Notes-design-passed

I thank everyone in this forum for interesting and usefull thread.

Best regards
Christian Nicoll
[ July 28, 2008: Message edited by: Christian Nicoll ]

[Joe San]

Congrats!

[Eric Chou]

Congratulations for passing the exam. Although you lost 36 points in locking section, you still did well with your assignment.
Could you tell me what is the reason the assessor does not like your locking mechanism? Is there any comment sent back to you?

[Kah Tang]

Congratulations!

What was your locking strategy by the way?

[Anirban Das Gupta]

Congrats Christian...

Anirban
(SCJP 1.4)

[Soroj Margun]

Congrats !!! That is a great score.

[Christian Nicoll]

Hello,

unfourtanly I don't konw why the accessor is not so really happy with my locking-implementation. The accessor did not post any reasons or further comments.

I've wrote a prosa-text of my locking-strategy. I changed only the names of the two classes into Facade.java and Implementation.java, because I don't want to violate any rules in this forum.

The locking-strategy is based on the two classes Facade.java und Implementation.java. Facade.java implements the interface DBAccess.java and so has to provide the locking methods. But the really locking logic is in the class Implementation.java, and the Facade.java forward only the request of locking and unlocking to the class Implementation.java. The Implementation.java has a map<Long, Long> which contains all the locked record(-numbers) with their cookie. To lock a record, first the map will be checked, to see if the specific record-number still locked by another client. If it this is the case, than the thread will go into a waiting state. After the locked record is unlocked, all waiting threads will be notified and check again if they can now lock the record. If this is the case, than the lock method will lock the specific record over the record-number and will return a cookie. It is now only possible to modify the record if a Thread knows the specific lock-cookie.

Further I synchronzied all the methods which directly access the Database-Fiel over a RandomAccessFile-instance

[ July 29, 2008: Message edited by: Christian Nicoll ]

[Jethro Borsje]

Perhaps you should also have synchronized on the locking Map (Map<Long,Long> ? It seems to me that two threads might try to get a lock on the same record at the same time using your approach...

[Christian Nicoll]

Hi Jethro,

your advice is absolut correct and I've did that too. I forgot it to wrote about it in my above locking-strategy.

My both lock- and unlock-methods of my Implementation.java class surround the whole code of these methods with a synchronized statement like this:

synchronized(map)
{
  //Implementation code 
}  
 

Best regards,
Christian
[ July 29, 2008: Message edited by: Christian Nicoll ]

[Kah Tang]

Originally posted by Christian Nicoll:
Hi Jethro,

your advice is absolut correct and I've did that too. I forgot it to wrote about it in my above locking-strategy.

My both lock- and unlock-methods of my Implementation.java class surround the whole code of these methods with a synchronized statement like this:

synchronized(map)
{
  //Implementation code 
}  
 

Best regards,
Christian

[ July 29, 2008: Message edited by: Christian Nicoll ]

I think I have an idea of why they substracted points for this solution. Synchronizing on the map would mean that everytime a map.notifyAll() occurs, some cpu cycle will be consumed to check if the lock released is on the right record. This somewhat different from the assignment where it says, that only cpu cycles are allowed to be consumed if the record holding the lock is released.
[ July 29, 2008: Message edited by: Kah Tang ]

[Jo�o Batista]

First, congratulations! You managed to go pretty well in the overall!

Second, did you handle deadlock? I am not sure that this is actually needed (there is nothing on the specs about it), but you never know.
That infamous score got me pretty scared in the beginning, but there are threads discussing locking tests, which helped a lot at making the test cases.
Also, modifying code to create artificial conditions is a good thing to do.

[Jethro Borsje]

Originally posted by Christian Nicoll:
[QB]Hi Jethro,

your advice is absolut correct and I've did that too. I forgot it to wrote about it in my above locking-strategy.

My both lock- and unlock-methods of my Implementation.java class surround the whole code of these methods with a synchronized statement like this:

synchronized(map)
{
  //Implementation code 
}  
 

That sounds good. Do you also sync on your RAF (or in memory map of records) while locking in order to see if there is a record with the given recNo?

[Christian Nicoll]

Hi Ranchers,

thanks for your replies.

@Kah: Your are right. Everytime the program sends a notfiyAll a small amount of cpu-cycle will be consumed. There are several threads in this forum which discuss this topic. In several of threads reads I read that ranchers used the same logic without any deductions in the locking section.

@Jo�o: While the development I had several deadlock-situations. I found them by reading this thread. I used also Mihai Radulescu code to test my application. I don't believe that deadlocks are the reasons for the mystery 44/80 score, because I am think that I've catch them quite well

@Jethro: I synchronized in the Implementation.java class on the record-map. In my lock- und unlock-method I check further the (synchronized) map to know if a record exists or not. I don't read a this moment any information from the database-file, only the Hashmap-Object. I think this safe, because if someone other wants to change or delete a record, he has "take" a cookie, and so to lock (synchronized on map) the specific record.

Best regards,
Christian Nicoll