Forums Register Login

The Mysterious 44/80 Locking score.

+Pie Number of slices to send: Send
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.

Hope that helps.

Mark
+Pie Number of slices to send: Send
What scenarios can we think of that we should be testing so we do not fall victim to the 44/80?
+Pie Number of slices to send: Send
Of course it helps! Thank you, Mark!

Phil.
+Pie Number of slices to send: Send
I'd say a scenario with multiple users and multiple machines all trying to get at a record at the same time.

And my favorite solution. KEEP IT SIMPLE!!!

Mark
+Pie Number of slices to send: Send
Thankyou Mark,

That is very good to know.

Regards, Andrew
+Pie Number of slices to send: Send
Hi,

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.

Thanks,
Javini Javono
+Pie Number of slices to send: Send
Hi,

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?

Thanks,
Javini Javono
+Pie Number of slices to send: Send
Hello,

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
+Pie Number of slices to send: Send
 

Originally posted by paul_ov:
Hello,

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.
+Pie Number of slices to send: Send
Hi everyone,

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.

Regards, Andrew
+Pie Number of slices to send: Send
Andrew, I am behind you.

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.

It is very clear.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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?
+Pie Number of slices to send: Send
Hello Peter,

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.
Get off me! Here, read this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1798 times.
Similar Threads
Passed finally with 86%!!!
re: NX: URLyBird Passed 366
Passed SCJD
Passed SCJD with 373/400
Passed !!
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 05:54:18.