aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Does nest locks really bad? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Does nest locks really bad?" Watch "Does nest locks really bad?" New topic
Author

Does nest locks really bad?

Michael Dreese
Ranch Hand

Joined: Apr 02, 2003
Posts: 45
Hi all,
I have a question on my lock method. I'm planning to have two synchronized blocks on two different objects for my lock method. One is a static Map and the other one is a DataOutputStream.
However, in the threading chapter of Java Developer Exam with J2SE 1.4, it said "Don't nest locks. If you have two synchronized blocks on two different objects in your excution path, your're probably heading down the wrong road."
I'm confused now. Am I doing some wrong here? My assignment is about the home improvement contractors.
The signature of lock method:
public long lock(int recNo) throws RecordNotFoundException
The return long value is a cookie number (some kind of Client ID).
Can anyone help me to review my idea? I think I can do the locking with two synchronized blocks, but I'm just wondering whether it is a good design or not. Or is there any alternatives?
Thanks for your time and reading my post.
Michael
[ April 06, 2003: Message edited by: Michael Dreese ]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Michael,
If you can avoid nesting locks, then do so. if you can't, then make sure you're always, always, always, always locking and unlocking them in the same order: that is, first lock A, then B to lock, then B followed by A to unlock. In the book, I provide examples of exactly what not to do in this regard.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ April 06, 2003: Message edited by: Max Habibi ]

Java Regular Expressions
Michael Dreese
Ranch Hand

Joined: Apr 02, 2003
Posts: 45
Hi Max,
Thanks for your reply and your book is an excellent book for preparing SCJD exam.
In your book's project, since every DVD records has its own file. Unlike my project, there is only one single db file for storing all the records. That's the reason to make me think that I should lock the DataOutputStream/DataInputStream to avoid concurrent read/write on the same file. I believe there is a better way to deal with the input/output file, but I still couldn't come up with any idea for that.
Can you (or anyone) tell me what I'm missing here? I'd highly appreciate your helps.
Cheers,
Michael
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Michael,
We really struggled with that aspect of the book, because while we wanted to be like Sun's exam, we didn't want to be too close too it. But to answer your question: as I see the exam(and I was involved with the beta), I don't really see a need for the sort of read lock you're talking about. Can you produce the condition you're talking about? Remember, IO blocks per call.

All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ April 06, 2003: Message edited by: Max Habibi ]
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

However, in the threading chapter of Java Developer Exam with J2SE 1.4, it said "Don't nest locks. If you have two synchronized blocks on two different objects in your excution path, your're probably heading down the wrong road."

It is considered a bad programming practice to synchronize on different objects in nested synchronized blocks. This is a common source for deadlocks, so Sun is giving you a free tip. Note that if your shared resources are accessed only from the synchronized methods of a class, there is no need to synchronize on those objects explicitely.
Eugene.
Michael Dreese
Ranch Hand

Joined: Apr 02, 2003
Posts: 45
Originally posted by Max Habibi:
We really struggled with that aspect of the book, because while we wanted to be like Sun's exam, we didn't want to be too close too it.

I think the book is good enough. Let's say if the project in the book is too close to the Sun's one, then there is no point of taking the Sun's exam. I do think the book is just showing us some introductions of developing mid-size software by using J2SE 1.4.

But to answer your question: as I see the exam(and I was involved with the beta), I don't really see a need for the sort of read lock you're talking about. Can you produce the condition you're talking about? Remember, IO blocks per call.

My concern is that when I only lock the record, I
can't make sure that if I want to read/write from a file, it won't have concurrent access. My idea is that every time when I need to read/update/delete a recod, I will get DataInputStream/DataOutputStream to do those operations in the db file. What do you think the way I'm handling the db file? Am I going to the wrong direction?
Cheers,
Michael
Michael Dreese
Ranch Hand

Joined: Apr 02, 2003
Posts: 45
Originally posted by Eugene Kononov:
It is considered a bad programming practice to synchronize on different objects in nested synchronized blocks. This is a common source for deadlocks, so Sun is giving you a free tip. Note that if your shared resources are accessed only from the synchronized methods of a class, there is no need to synchronize on those objects explicitely.
Eugene.

Thanks for your reply, Eugene.
I understand your point; however, I'm given with a interface called DB and my data access class must implement DB (not doing so will cause automatic failures). All the methodes in DB are not synchronized.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Michael Dreese:

My concern is that when I only lock the record, I
can't make sure that if I want to read/write from a file, it won't have concurrent access. My idea is that every time when I need to read/update/delete a recod, I will get DataInputStream/DataOutputStream to do those operations in the db file. What do you think the way I'm handling the db file? Am I going to the wrong direction?
Cheers,
Michael


Let's break it up a little bit. If you want lock a record, there's no reason that you can't allow concurrent reads on that record: in effect, a dirty read. However, that's not really a problem per se: dirty reads are ok in this system, AFIK. However, if you do want to lock for reads, you always can. However, the problem here is that a readAll operation could end up taking an awefully long time.
OTOH, if you want to update a record, then your locking should keep other clients from trying to modify the record at the same time, so you're ok there too. I'm still not seeing a need for a nested lock. Am I missing anything?
M
[ April 06, 2003: Message edited by: Max Habibi ]
Michael Dreese
Ranch Hand

Joined: Apr 02, 2003
Posts: 45
I'm clear now after you mentioned about the dirty read.
I was messing up with the idea on read/write at the same time.
Can you explain a bit more about the readAll operation? I think this operation will be useful on showing GUI-Client for all records. I know I can lock one record at a time to read throught all the records.
Also, does the beta exam use some kind of (long type)cookies? If it does, how can I generate the unique number? I know that I can use "count" to do that, but is there any better way?
Thank you so much.
Cheers,
Michael
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Does nest locks really bad?
 
Similar Threads
How to check wether object is currently locked
Clarification in Class Type's in Java
B&S: OK to assume lock(), update(), unlock() called from same thread?
"A thread can aquire more than one lock"-K&B
static, instance methods, Thread safe issue