Originally posted by Aleh Barysevich:
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Aleh Barysevich:
At the same checkRecordValidity(recNo) is the method that must be synchronized itself on some other object (e.g. RAF-object if you do not implement any cache and read directly from file).
Originally posted by Aleh Barysevich:
Is it ok to have nested synchronized blocks or maybe there are ways to get rid of them in this situation. Please help.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Why do you have to synchronize it on some other object?
Then when you have determined that logically you cannot deadlock, then add that proof into your documentation.
Originally posted by Aleh Barysevich:
Frankly speaking this was the main reason for my question: is it ok just to add a proof in my choices.txt? Won't be I penalize� just for having such a coding construction in my code?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
By the way, I would strongly recommend that everyone go through the logical exercise of determining whether there are any conditions that logically might lead to deadlock (much more important that trying to "prove it" using coded tests). You may like to write it down in either the point form or the tree form that I have done above. Then when you have determined that logically you cannot deadlock, then add that proof into your documentation. It may save the examiner a lot of time if they can see that you have already done the work for them: they will just need to validate your proof <http://www.javaranch.com .
SCJP, SCJD, SCWCD, SCBCD
You get good luck from rubbing the belly of a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|