• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Synchronization and Data/Schema

 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In another thread earlier today there was some discussion on the createRecord method and locking. It was suggested that I create this post to continue that discussion, but deal specifically with some of the questions raised at the end.
Here is the summary of the situation:
I have 1 instance of a Data singleton class
This Data instance has one instance of a Schema class.
Schema has the cached list of rooms and also the RandomAccessFile.
My Data methods that update the file/cache are all synchronized and they keep the file/cache in synch.
My update/delete methods expect a lock cookie in the signature to ensure that specific record locking is done before entering the synchronized update/delete method. This is done similar to the approach in Max's book.
1. By having 1 data instance, one RandomAccessFile pointer and synchronizing on the Data manipulation methods, I won't have to do any further synchronization on the cache list or file handler. Is this assumption true?
2. I am currently synchronizing a couple methods in my schema class ---
getHotelRooms() (i.e. the cache list) and
addHotelRoom() (i.e. add to cache list)
I use the getHotelRooms in my Data create, update, delete, and find methods all of which are synchronized on the Data instance. I use the addHotelRoom in my Data create method.
My Data instance is set up following the normal singleton approach - public getInstance method with a private constructor to enforce only one instance. However, my Schema constructor is public. So even though I force my one Data instance to only have one instance of the Schema, I can't really prevent others (i.e. Sun's dreaded automatic failure test) from constructing instances of Schema, perhaps all pointing to the same RandomAccessFile pointer.
Do I have deadlock issues lurking?
3. Would I be better off to have my Schema be some type of inner class to my Data object? Then I wouldn't have to synchronize schema methods or worry about public constructor because only my Data instance could get at them.

Thoughts???
TJ
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Terry,
1. True only if your read method is synchronized too.
2,3 Or give your Schema class the package level access.
Best,
Phil.
 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Phil. One more question - even if I make the Schema package access only, might I still have deadlock issues if I synchronize both the methods within the Schema class and the Data manipulation methods that could be calling the schema class.
I'm trying to figure out if it is safe to remove the synchronization on the Schema classes. I know Max really warns against nesting locks on p. 122 in his book, and I fear this might be one of those situations. Seems like it would be safe to remove the Schema synchronization, since there is only 1 Data instance and it can only have 1 instance of Schema. My fear is that old "auto-failure" thing if I miss something.
What do you think?
TJ
 
Bill Robertson
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Terry,
Wasn't the original issue calling synchronized methods in the Schema
class from an already sychronized process in the Data class. Thus
making the synchronization in the Schema class redundant - given its
a singleton and its methods are only called by Data through a schema handle within a synchronized method/block?

For example, you have a delete method in Data:
public synchronized int delete(int record, long cookie) {

.....
schemaHandle.getContractor(record) // Make sure record exists by calling
// getContractor in Schema class
}
QUESTION: Does getContractor() on Schema need to be synchronized?
I think it may be proper, but this lead us to the possible deadlock issue.
Any Help?
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Terry,
Thanks Phil. One more question - even if I make the Schema package access only, might I still have deadlock issues if I synchronize both the methods within the Schema class and the Data manipulation methods that could be calling the schema class.
I'm trying to figure out if it is safe to remove the synchronization on the Schema classes. I know Max really warns against nesting locks on p. 122 in his book, and I fear this might be one of those situations. Seems like it would be safe to remove the Schema synchronization, since there is only 1 Data instance and it can only have 1 instance of Schema. My fear is that old "auto-failure" thing if I miss something.

Sorry for the delay, but I missed your reply on December 24.
With your design (Schema with no public access, Schema accessed only from a Data singleton where all public methods are synchronized), you don't need any further synchronization in Schema.
Now even if you keep some synchronization in Schema, you have no risk of deadlock in this case. As Schema as no public access, all possible entry points in your Data/Schema system are in Data, ensuring a consistent order in acquiring locks (Data alone or Data then Schema, but never Schema then Data).
Best,
Phil.
 
Bill Robertson
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks a ton phil, this is what I was looking for and I think Terry
got his answer also
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic