aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes VICTORY: Locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "VICTORY: Locking" Watch "VICTORY: Locking" New topic
Author

VICTORY: Locking

Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
The code that does the locking trick is this little piece of functionality:



If you think I made a mistake, please correct
[ August 29, 2004: Message edited by: Anton Golovin ]

Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Vinay Selvaraj
Greenhorn

Joined: Aug 25, 2004
Posts: 6
You'll need to synchronize the method for it to work properly. More than one method may be running this method at the same time.


Vinay Selvaraj<br />- SCJP 1.4<br />- SCJD (in progress)
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by Vinay Selvaraj:
You'll need to synchronize the method for it to work properly. More than one method may be running this method at the same time.


My Data class is synchronized.
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
And it doesn't loop.

Loop = CPU cycles

--

// continue

or rather:

/* no way should this have happened
something real bad has gone off
log it properly
probably shut down the app. */


SCJP 1.4, SCJD
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by mike acre:
And it doesn't loop.

Loop = CPU cycles

--

// continue

or rather:

/* no way should this have happened
something real bad has gone off
log it properly
probably shut down the app. */


What do you mean it does not loop? Is there a better way to check for a record being unlocked than looping?
[ August 29, 2004: Message edited by: Anton Golovin ]
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Okay it loops.
Just not in the trivial way, forgive me.

And that is exactly how you should do it,
well it could be if we new what isLocked(int) does.
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by mike acre:
Okay it loops.
Just not in the trivial way, forgive me.

And that is exactly how you should do it,
well it could be if we new what isLocked(int) does.


Sorry, here's the isLocked method:

Vinay Selvaraj
Greenhorn

Joined: Aug 25, 2004
Posts: 6
Originally posted by Anton Golovin:


My Data class is synchronized.


Only methods and code blocks can be synchronized. Did you synchronize the method that calls waitForUnlock?
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by Vinay Selvaraj:


Only methods and code blocks can be synchronized. Did you synchronize the method that calls waitForUnlock?


Exactly. Every public method of Data class is synchronized; Data class is thread-safe. Actually, a better solution would be to leave Data methods thread-unsafe and have calling code synchronize on the class instance: it would provide more flexibility of design decisions in business logic.
[ August 29, 2004: Message edited by: Anton Golovin ]
Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
Hi Anton,

I am just starting sorting out my locking mechanism, so I don't know how much I can help on that front (I think not at all). However, looking at your isLocked method, I think it would be neater to not have



but instead have

?

I know it's a small technicality, and a digression from the point of the thread, but it just gets rid of an (seemingly to me at least) uncessasary "if".

Michal
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by Michal Charemza:
Hi Anton,

I am just starting sorting out my locking mechanism, so I don't know how much I can help on that front (I think not at all). However, looking at your isLocked method, I think it would be neater to not have



but instead have

?

I know it's a small technicality, and a digression from the point of the thread, but it just gets rid of an (seemingly to me at least) uncessasary "if".

Michal



I agree. I often program in the evening, and you have to make the allowance for tiredness It is of course the way you suggest.
Udham Singh
Greenhorn

Joined: Jun 18, 2004
Posts: 13
Vinay,

Why does he want his method to be synchronized? I've done multi-threaded programming only in C and well I am not sure if I understand synchronized methods all that well. But here is what I am thinking. Say threads I and II want to lock records 142 & 137 respectively. Synchronizing the method will make make one wait for the other unnecessarily. Wouldn't you want them to these two threads to acquire the locks concurrently?

Thanks
Vinay Selvaraj
Greenhorn

Joined: Aug 25, 2004
Posts: 6
Udham ,

What if those two thread are trying to lock the same record. To make it thread safe, you'll have to have a synchronized block somewhere. Smaller the better.
Udham Singh
Greenhorn

Joined: Jun 18, 2004
Posts: 13
I agree with you. But as you yourself said "Smaller the better." Maybe just synchronizing on lock, unlock & isLocked is not such a bad idea. But synchronizing every method in the Data class (as Anton has suggested) seems to be a pretty big lock.

Comments.
Vinay Selvaraj
Greenhorn

Joined: Aug 25, 2004
Posts: 6
Yes. When I said "smaller is better", I meant synchronize only what must be synchronized. In some cases, it may just be better to synchronize a small block of code within a method and not the entire method.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Vinay Selvaraj:
Yes. When I said "smaller is better", I meant synchronize only what must be synchronized. In some cases, it may just be better to synchronize a small block of code within a method and not the entire method.


I agree, if you have access to a copy of Doug Lea's "Concurrent Programming in Java" he provides a great deal of advice on this topic. The summary of the basic rules is found on page 6:

1 - always lock during updates to object fields
2 - always lock during access to possibly updated object fields
3 - never lock when invoking methods on other objects

In this his use of the term lock is equivalent to the use use of synchronized. As you can see by the low page number, this is very basic stuff.

For our case its rule 3 that is most important. It often has to be broken , but should always ring an alarm when you do. The Data class should synchronize the smallest possible code blocks on the RandomAccessFile (or record cache) when accessing that file and on the Map containing the record lock cookies when doing lock(), unlock() and isLocked().

To avoid problems with deadlock the lock method should first obtain a lock cookie for an arbitrary numeric resource before checking if that resource is a valid record, then check for record validity and unlock the resource if the number doesn't represent a valid record. This prevents the nesting of synchronized blocks that could result in deadlock. If it turns out that someone has created the record after you locked it, but before you unlocked it because it appeared to be deleted, there is no conflict, they may wait momentarily if they try to lock it, and you just treat it as deleted.

You could check first, and save the run through the locking code in most cases of RecordNotFound, but you will still have to check afterwards if you don't synch on the RandomAccessFile, this is what Max does in his example.
 
 
subject: VICTORY: Locking