After 4 week waiting and one email to SunCert, I got my result today and passed SCJD. I am surprised at OOD and Data Sore parts. Thank all Javaranchers here. Without your help, I can't pass SCJD. Though the score is not very good, I am still very happy. At first I would like to donate some menoy to keep Javaracnh's running. But right now, I want to buy some Javaranch stuff, like Regular Moose Mug. By this way, I not only keep javaranch run but also proves I belong to Javaranch. Thank you all again.
Test: Sun Certified Developer for the Java 2 Platform (310-027) Date Taken: 2005-03-04 07:58:47.577 Site: ti8 Grade: P Score: 359 Comment: This report shows the total number of points awarded for each section. The maximum number of points is 400, to pass you need a score of 320. Section Summary: Section Max Actual Points Points General Con: 100 89 Documentation: 70 62 OOD: 30 30 GUI: 40 28 Locking: 80 80 Data Store: 40 30 Network Server: 40 40 Total: 400 359
Any abstract, vague pointers to help the rest of us. Particularly with respect to your fantastic 80/80 locking score!
Joined: Jul 01, 2003
I posted the locking part of my choice.txt. Hope this should help you.
Thread Queue ========== In Data.java, the create/read/find functions are executed by the current thread after the only one Data object is locked by the current thread so that the basic transaction can be safe. Also, in the multiple-thread environment, the locking implementation of update/delete function I chose is to maintain a thread queue for each record. Because a thread must call lockRecord() to lock the thread specified record before calling the method updateRecord()/deleteRecord() and must call unlock() to unlock the thread specified record after calling the method updateRecord()/deleteRecord(), the thread queue mechanism can be done in lockRecord() and unlock(). There are 3 elements to the thread queue mechanism, long lockCookieCount to generate unique lock cookie, HashMap lockedRecNos to stroe which record is being locked and to store a thread waiting list corresponding to this record, and LinkedList threadWaitingList to store all the waiting threads which wait for the same record. Every time a thread accesses ockrecord(), lockCookie pluses one to generate a unique number and the thread name is set with this unique number. When more than one threads want to access the same record, the very first one thread locks the thread specified record and make an entry in HashMap lockedRecNos to notify other threads that the very first thread is being using the record. Then, all other threads have to wait for their turns and are stored in LinkedList threadWaitingList which is also stored in HashMap lockedRecNos. After the very first thread finishes its work, the thread queue wakes up the next thread, removes the very first thread and then allows only the next thread to access the same record. Due of the thread queue mechanism, threads wanting to access the same record can be executed one after one in the sequential order (first in first out with LinkedList objects) and then make basic transaction safe. And no waiting thread consumes CPU cycles until it is waken up.
Congrats Steve! Great job overall, especially on locking!
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
The only one means Data.java implements Singleton Design Pattern so there is only one Data.java instance. A thread trying to do CRUD must lock the "only one instance" to keep transaction safe. I don't lock other methods by using synchronized key word. The synchronized didn't appear in my Data.java but in my Adapter. Hope this be helpful.
Joined: Jul 01, 2003
Dear joe lin
The regulations of javaranch don't allow me to release my source code. (But I would like to share it with you if the regulations allows.) If the word "share this perfected implementation " doesn't mean source code, please tell me more what you really need.
So correct me if I am wrong.You have a singleton (the Data) and all the clients use it read/write/delete/update etc. You don't need to sinchronized the data object because the cleints access it via some clients warppers/adaptors with and they synchronize (on Data instance). Somethig similar I found also in the Max book, he use a static vector to manage the current-in use elements.