need some help with locking....

[joel smither]

I'm doing the UrlyBird project. Im my application, a factory is used to give each client a unique proxy instance that contains the remote service object registered by the server. So each client is getting their own proxy instance which has effectively wrapped the remote service object. The remote service object has a Data object that provides implementations for readRecord, deleteRecord, updateRecord, etc.... The Data class used a RandomAccessFile.

Question 1.....
In terms of threading I need to prevent concurrent updates: My Data class has a LockManager object that has a synchronized lockRecord method that locks the record. Once this is done I can update the record, then I can call my LockManager unlock method (also synchronized)to unlock the record.
This should take care of simulataneous updates right? I plan on doing the same thing for deleteRecord.

Question 2.....
Almost every method in my Data class (ie. readRecord, updateRecord, etc) manipulates the file position indicator in my RandomAccessFile (the file that actually has the data). I need to ensure mutual exclusive access to the file poisition indicator as well. Is it acceptable to make every method in my Data class synchronized? I'm not sure if this is the right thing to do or not.

Any help would be deeply appreciated.

[peter wooster]

Your approach is very similar to mine. I have a Data instance for each client that is provided by a factory. This instance is a facade over the locking and database I/O facilities. I use an adapter that adds the RemoteException and a proxy that returns the interface to the same one provided by Sun.

I expose the locking and unlocking code to the client, ie. I use the rich client model, not the thin client model.

My Data class does not use any synchronization since each instance is single threaded for most activities and doesn't have shared data. The synchronization is in the LockManager and DatabaseTable singletons that provide all the low level support.

The LockManager synchronizes on a Map between resource ids (record numbers) and locking requests. The lock, unlock, and check methods use synchronized blocks.

The DatabaseTable synchronizes on the RandomAccessFile. The open, close, readRaw and writeRaw methods that do the actual I/O use synchronized blocks.

[joel smither]

Thanks for the info Peter.

My Data class has the readRecord, createRecord, updateRecord methods that do the low level I/O (i.e. the seek to the proper position in the file, actual read and write, etc). Don't I need to synchronize any method that does an fseek because 2 clients could seek at the same time?

Also, with respect to the LockManager....all the methods in my LockManager class are synchronized...the methods in th class use a Hashmap to maintain information on which records are locked. The Hashmap is not a synchronzied collection, I just have a synchronized lock and unlock method in the LockManager class.

Does anyone see any problems with this approach?

[peter wooster]

Originally posted by joel smither:
Thanks for the info Peter.

My Data class has the readRecord, createRecord, updateRecord methods that do the low level I/O (i.e. the seek to the proper position in the file, actual read and write, etc). Don't I need to synchronize any method that does an fseek because 2 clients could seek at the same time?

Also, with respect to the LockManager....all the methods in my LockManager class are synchronized...the methods in th class use a Hashmap to maintain information on which records are locked. The Hashmap is not a synchronzied collection, I just have a synchronized lock and unlock method in the LockManager class.

Does anyone see any problems with this approach?

The I/O methods should syncrhonize on the RandomAccessFile, this can either be a static variable in the Data class or an instance variable in a singleton I/O class. Any method that does {seek,read} or {seek,write} will need to synchronize on the raf. I use a singleton and have readRaw and writeRaw methods that simply read or write a whole record as a byte array. these methods get called by the CRUD methods in the Data facade.

The LockManager should be a singleton and the lock and unlock methods will need to synchronize on the Map that stores the record->lockRequest pairs. You should try to design your I/O and Lock classes so that there is no nested synchronization, or if you do need it make sure it's always done in the same order to prevent deadlock situations.

[joel smither]

Instead of synchronizing on the RAF, can't I just synchornize the methods that do a fseek, file write, file read, etc. I don't understand the difference? If the methods are synchronized that means only one method is using the file at a time right?

Also, when you say synchronize on the Hashmap, you're talking about a sunchronized block like:
synchronized(Hashmap)
{
...
}

what's the difference between using the synchronized block and having the methods in the LockManager class be synchronized. It seems they are doing the same thing...?

[Kris Reid]

I don't understand how this is meant to work.
Is this the correct?

update(int recNo, String[] data) {
lock(recNo)
//update
unlock(recNo)
}

if so how can you lock an object other then in a sync block?

[peter wooster]

Originally posted by joel smither:
Instead of synchronizing on the RAF, can't I just synchornize the methods that do a fseek, file write, file read, etc. I don't understand the difference? If the methods are synchronized that means only one method is using the file at a time right?

Also, when you say synchronize on the Hashmap, you're talking about a sunchronized block like:
synchronized(Hashmap)
{
...
}

what's the difference between using the synchronized block and having the methods in the LockManager class be synchronized. It seems they are doing the same thing...?

You can simply synchronize the methods, doing that is equivalent to a block containing the method code synchronized(this). If the LockManager and IOManager are singletons this will work. If the Data class is not a singleton this will not work, since each thread may have a different object, you then need to synchronize on the static RandomAccessFile.

[Frans Janssen]

I choose to synchronize on a monitor object representing the record. This guarantees that the server has at that moment exclusive access to that record, whilst allowing different records to be accessed simultaneously.

I create a new RandomAccessFile object for each file access operation (I am not sure if this is perhaps an "expensive" solution in terms of performance, though). That way I don't have to worry about different clients moving each other's file positions around.

Frans.