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?
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.
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.
Joined: Jan 15, 2005
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?
Joined: Jan 13, 2005
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.
Joined: Jan 15, 2005
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.
Joined: Apr 08, 2003
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 ]