aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Java 1.5 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 "Java 1.5 Locking" Watch "Java 1.5 Locking" New topic
Author

Java 1.5 Locking

John Winstanley
Greenhorn

Joined: Apr 08, 2003
Posts: 14
Hello I'm working towards Bodgitt and Scarper 2.1.2,

I've noticed a few developers have tried to create solutions using Java 5.

I can see how generics and enumerations will make my life a little easier but I'd like to know if anyone is using classes in the package java.util.concurrent to implement a locking mechanism?

This is my lock method.



The Lock method waits until the locks collection does not contain
the recNo, then it inserts a new lock into the locks collection, with the cookie as the key.

1. Is it inefficent to synchronise on the whole collection?

2. Would it be more efficent to synchronise on an object that represents the record we are trying to lock, so that different threads can access the arraylist at the same time?

3. So could I instead use an ArrayList of java.util.concurrent.locks.Lock objects one for each record and have my lock method wait on a particular element in the array list. Does this seem like a sensible approach?

4. Consider this situation,

Thread A obtains lock on recNo 1
Thread A tries to obtain lock on recNo 1

Does deadlock occour? If so how can I handle this situation?


John
Josh Allen
Ranch Hand

Joined: Jan 15, 2005
Posts: 37
Originally posted by John Winstanley:
3. So could I instead use an ArrayList of java.util.concurrent.locks.Lock objects one for each record and have my lock method wait on a particular element in the array list. Does this seem like a sensible approach?

I'm not an expert on the new concurrent package but using it this way would be equivalent to just using a monitor on the Record, i.e.
I'm using the concurrent package's read/write lock to guard the in-memory database cache, as opposed to just using mutex monitors.
Sesha Nandyal
Greenhorn

Joined: Jan 13, 2005
Posts: 2
The way, I have implemented it is as follows:
In Data.java
lock():
//Guard statement - validate the recourd number that is passed
Get the record

Check on the record object if its held by the current thread

if not, call the lock() on the record object


In Record.java
Have an instance variable of type lock
Define methods called lock, unlock and isLockedByCurrentThread. And in each one of these methods, delegate the call to the instance variable's lock methods.

Sesha
Josh Allen
Ranch Hand

Joined: Jan 15, 2005
Posts: 37
I can't see any difference between doing that and using synchronize, other then a some unnecessary work. What benefit do you think there is?
Sesha Nandyal
Greenhorn

Joined: Jan 13, 2005
Posts: 2
The Lock class of JDK1.5 does all the work for me. I delegated the calls to the the Lock object (an instance variable of Record) and was assured that I had lock on the Record object. I guess - one less work.
Josh Allen
Ranch Hand

Joined: Jan 15, 2005
Posts: 37
If you can just use why bother doing this
Plus the extra instance variable per record, plus the code for methods lock() and unlock()? What benefit do you get, as like I say it seems like unnecessary work.
John Winstanley
Greenhorn

Joined: Apr 08, 2003
Posts: 14
Thanks for the input, I've not been convinced of any real advantage of using the new concurent package so far but I'll play around with it a little more to see what happens.

To synchronise on the record itself as you suggest don't I have to cache the data?
[ January 21, 2005: Message edited by: John Winstanley ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java 1.5 Locking