Here is an anonymous unofficial answer I have received at JavaOne, by someone really really close to the certification and knows about grading.
Basically if you get 44/80 means that the locking does not work in all cases. That there is a scenario that the examiners have run that shows the locking schema that you use does not fully lock in all concurrent scenarios.
Mark Spritzler wrote: I'd say a scenario with multiple users and multiple machines all trying to get at a record at the same time.
I'm writing because I don't understand the implications behind the above remark, a remark which others appreciate (because they see the implications immediately).
In my design and implementation, for every client there exists one data object on the server.
The following scenario works fine for me: One computer, one application, multiple threads each representing a user, accessing the database through the local or remote server.
I don't immediately see how the situation changes when you assume multiple machines.
In the month of July so far, two people received a score of 80/80 in locking: Adrian Popescu and Maria Lepschy.
Did you all take any special action to ensure that a thread did not starve waiting for a record lock? Or did you simply call notify() or notifyAll() (which one?) and let the system determine which thread would be chosen randomly next?
I'm wondering if the score will be deducted if one doesn't throw the RecordNotFoundException for the lock/unlock/islocked functions. Maybe people just check their locked records list and don't check in the database if the record actually exists.
I'm wondering if the score will be deducted if one doesn't throw the RecordNotFoundException for the lock/unlock/islocked functions. Maybe people just check their locked records list and don't check in the database if the record actually exists.
Anyone ideas on this?
Paul
I was infact struggling with this today myself, whether to throw an exception when the recno does not exist in the database. Specially in the case of a isLocked(), why check if the recNo actually exists in the db. Simple return false if the recNo is not on the locked records list.
Anyway, I have implemented, the extra step to throw RNFException if the recNo does not exist in the db.
For the 44/80 score, I am guessing most of them have implemented the locking correctly for updates, deletes, but when it comes to reading, maybe they sneaked in dirty reads.
I strongly recommend you check your instructions for the sentence "Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.".
It is not a must requirement, but (for those who have a RecordNotFoundException) it sounds like it is something the assessor may check for. All you need is one common method that performs checks for non-existant/deleted records, and have all your public methods call it - simple.
I just substract all my code to checkExist(int recNo). just check the RecordNotExistException. Then almost all the public methods with the exception will call it.
My lock and unlock methods (and not only these methods) check whether the record exists and throw a RecordNotFoundException if it does not, yet I received 44/80. My locking mechanism would not work if records are created and removed, but my create and delete methods were NOPs (throwing UnsupportedOperationException). I felt I did not need to make a (more complicated) locking mechanism what would work also work in cases my application did not support anyway. I suppose they have something on their checklist saying that the locking should work in all cases and forgot that it would not be logical to do this in cases like mine.
Originally posted by Dieskun Koper: My lock and unlock methods (and not only these methods) check whether the record exists and throw a RecordNotFoundException if it does not, yet I received 44/80.
Did you check that the record still existed after the lock completed?
No, I did not. If the record would be removed after the record existence check, while my locking code is running, it will not throw a RecordNotFoundException. As my delete method is a NOP and my map of records is an unmodifiable (Collections.unmodifiableMap), this should be okay. If I were to implement the delete method, my locking mechanism won't work. The case you mention is one of several in which it would break. I did explain this in my choices.txt.
Post by:autobot
Get off me! Here, read this tiny ad:
a bit of art, as a gift, the permaculture playing cards