File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Suggested Locking Solution 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 "Suggested Locking Solution" Watch "Suggested Locking Solution" New topic
Author

Suggested Locking Solution

Mark Thomson
Greenhorn

Joined: Jul 20, 2004
Posts: 15
I am getting to the stage where i am thinking about the locking solution to be implemented in my B&S solution.

Please comment on my suggested approach and my questions.

1. I want to have multiple instance of my Data Access class. Each instance will have 2 static members. A RandomAccessFile and a collection ( to store my locked records)

1. Physical locking

For physical locking I will be synchronzing on the RandomAccessFile object shared across all instance of Data class

2. Record Locking

For record locking I will be using the static collection

WHen i write / update / delete a record I will follow the process below:

1. Lock record
2. Lock file
3. Update File
4. Unlock File
5. Unlock record

Now i am a little worries about this approach in terms of deadlocks. From what i understand there is no way this locking can cause a deadlock as the File and record locks are mutually exclusive. Is this correct??

I am also a little unsure of implementing the Data layer in this way ( multiple instances ) as I am ultimately locking on a single instance of my RandomAccessFile. ( not allowing concurrent reads / writes etc )

Any thoughts here???

I suppose I don't want to have multiple RansomAccessFile objects as I am worried about corrupting the underlying file. Is this a valid concern if I was to use multiple RandomAccessObjects??


SCJP
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Mark Thomson:

1. I want to have multiple instance of my Data Access class. Each instance will have 2 static members. A RandomAccessFile and a collection ( to store my locked records)

I'm doing URLyBird so my specs are a little different. I need to provide a Data class that implements a DBAccess interface. I use mulitple instances of the Data class, these act as Facades to DatabaseFile and LockManager Singletons.

1. Physical locking

For physical locking I will be synchronzing on the RandomAccessFile object shared across all instance of Data class


This should be good, I do this in the single instance of the DatabaseFile class.

2. Record Locking

For record locking I will be using the static collection

WHen i write / update / delete a record I will follow the process below:

1. Lock record
2. Lock file
3. Update File
4. Unlock File
5. Unlock record

Now i am a little worries about this approach in terms of deadlocks. From what i understand there is no way this locking can cause a deadlock as the File and record locks are mutually exclusive. Is this correct??

The lock and unlock methods will synchronize on the Map and the I/O methods will synchronize on the RAF. It is possible if you aren't careful to end up with a deadlock. The obvious solution where you synch on the Map, check the file for record not found and then wait to get the lock can lead to deadlock.

My approach to this is to treat the "record locking" as locking an arbitrary numeric resource that has nothing to do with the physical records. Once I have the lock and have therefore exited from the synchronized block in lock, I check the file to see if the record is valid. This way there are no nested synchronized blocks in my code.


I am also a little unsure of implementing the Data layer in this way ( multiple instances ) as I am ultimately locking on a single instance of my RandomAccessFile. ( not allowing concurrent reads / writes etc )

Any thoughts here???

I suppose I don't want to have multiple RansomAccessFile objects as I am worried about corrupting the underlying file. Is this a valid concern if I was to use multiple RandomAccessObjects??

You must use a single RandomAccessFile object, or you won't be able to control concurrent use of the seek and read/write operations. Multiple Data objects are not needed, but they simplify a lot of other aspects of the code, such as dealing with lost clients.
Mark Thomson
Greenhorn

Joined: Jul 20, 2004
Posts: 15
Ok, after much debate I reckon I will go with the following solution for my Data Access Layer.

My data class has the following members:

1. Shared single RAF for file access and locking
2. Shared single Collection for record Locking
3. Shared DBMetaData class ( singleton ) for establishing db schema information
4. Shared CookieGenerator class ( singleton ) for generating unique lock cookies

You can create multiple instances of Data Class

My Data class is wrapped inside a DBAdapter class ( using the SUN DBAccess interface as reference type ) which implements a DBClient interface ( Adapter pattern )

Now I am debating wether to extract the File IO jobs ( read record / update / create record etc ) into a DbIO class. Do you think there is any benefit in this??

Also, currently my DBMetaData class ( singleton ) is responsible for configuring itself ( reading in the db schema and setting instance vars etc). Now i am not sure wether to leave this or to just use the DBMetaData class as a holder and give my Data/DbIO class( if i go down that route ) the responsibility of reading in the db schema??

Please let me know what you think.
Raj Nagappan
Ranch Hand

Joined: May 26, 2004
Posts: 38
Originally posted by Mark Thomson:

1. I want to have multiple instance of my Data Access class. Each instance will have 2 static members. A RandomAccessFile and a collection ( to store my locked records)

I am also a little unsure of implementing the Data layer in this way ( multiple instances ) as I am ultimately locking on a single instance of my RandomAccessFile. ( not allowing concurrent reads / writes etc )


You should be careful with this approach. If you are using RMI then only one instance of the server object (let's call it Data for the sake of simplicity) will be created. It will be run concurrently from multiple threads; one for each client connection.

I originally had a similar design except that each Data instance had its own RAF and no two RAFs could access the same record at the same time. Was all very safe, etc, but RMI kept executing the same shared Data instance.

Raj.


Raj Nagappan<br />SCJP, SCJD, PhD
Mark Thomson
Greenhorn

Joined: Jul 20, 2004
Posts: 15
When i get to my RMI part i am planning on using a DBAdapter factory to return me new instances of my Data class ( underlying ) so i reckon I will be ok in that respect
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Suggested Locking Solution