This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Does anyone ever fail the SCJD? I do not know anyone who has. Also, I have managed to stress test my application using 100 concurrently created threads performing random accesses to the database.... Does anyone have a good idea as to "how threadsafe" an application should be....There are capacity issues with the network/HW I am using. Cheers guys, /Niall
Everything I've seen makes it sound like describing "how treadsafe" your application performs is pretty much more important than making it completely threadsafe. On my design decisions, I was quick to point out the shortcomings of the system and my justifications for allowing these shortcomings to exist. Just be sure to thoroughly document your threading issues and you should be good to go. Good luck!
Niall, hi I have seen a couple of posts in the certification results forum from people who've failed, but I suspect that most people who fail prefer to keep it under their hat until they have better news. I know I would So that makes it a bit difficult to gauge what proportion of people fail... As to the threadsafe operation issue, I think there are two main facets: does the design you have implemented look reasonable on inspection of the code, and does it ever go wrong? These sound a bit banal, I know, but what I mean is: (1) Is it possible for the examiner to spot a flaw in your algorithm from looking at your code (for example, have you allowed one client to lock more than one record at a time, thus introducing the possibility of deadlock, have you properly handled a client with a lock disconnecting before it releases the lock, etc). If the examiner can't spot any glaring errors or omissions from inspection of the code, then... (2) Does the system actually perform correctly? Life, being what it is, guarantees that it is never possible to know that there are no bugs in a system. But all it takes is for one snafu to occur for you to know that there is at least one bug. Because the JVM specification leaves some details of thread implementation choices to the JVM vendor (and these might in turn be dependent upon platform) I would try to test my server on as many different OS's as possible (Linux, Windows, MacOS...). If I could get corrrect operation with 100 concurrent clients on 3 or 4 different OSs I would be more confident I'd done the right thing, design wise. (Of course, I wouldn't know for sure... )
Always proofread carefully to see if you any words out.
Hi Niall Yes, people do fail SCJD. Doing a search on the word "fail" in the subject line in this forum showed me 7 postings. Some of these people appealed to Sun and passed on appeal - others did not. There are no doubt other people who failed who:
did not have the word "fail" in the subject line,
or who posted in the certification results forum,
or who didn't tell people they failed.
I have no doubt that outside of JavaRanch there are people who are working on their assignments without assistance from others who are doing or who have done their SCJD, and for those people I would expect failure rates to be higher. The SCJD is not just given away - people do have to work hard for it, especially if they want a good score. I agree with Damian's comments about Thread Safety. I think too many people rely on creating a test case to "prove" that their implementation works instead of working out logically if there could be a potential for a problem. If you can do your code review as a first step to ensure that you cant see any potentials for thread issues, then do your testing after that. I think Kathy Sierra / Bert Bates mentioned that the examiner only has to spot a potential for failure - they do not have to prove that it will fail. Regards, Andrew
BEA 8.1 Certified Administrator, IBM Certified Solution Developer For XML 1.1 and Related Technologies, SCJP, SCWCD, SCBCD, SCDJWS, SCJD, SCEA,
Oracle Certified Master Java EE 5 Enterprise Architect
Joined: Jul 22, 2003
Thanks for the info guys. Therefore I can assume to a certain extent that there will not be too much emphasis put on the threading capacity of your code. In other words, networking capaacity is a lower priority to actual implementation of locking and the avoidance of deadlock etc. Also, What I have done is implement my code in such a way that a single client only locks a single record at any one time....performs the desired action on it and straight away unlocks this record. Therefore, there will never be a deadlock situation. Many regards guys and thanks for all the info. /Niall
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com