NX: [URLyBird] Problem about synchronize mechanism

[Robert Huang]

hi, all
My SCJD Assignment is URLyBird. Now I have some questions about the synchronize mechanism.
IN my design, I use the singleton design pattern to implement the remote object, which is RemoteDataImpl. That means there is only one instance of remote object running on server and every clinet thread can only obtain the same remote object instance. And the RemoteDataImpl class has a static instance of Data class, which implements the DB interface ( provided from Sun Enterprise) and uses a RandomAccessFile object to interact with the database file. Each client's request, such as "Search" and "book", should be actioned through using some business methods of the unique instance of RemoteDataImpl class, which subsequently call some methods of its static instance of Data class.
originally, I have two choices to implement the synchronize mechanism. One, synchronize all methods of Data class, which are related to database operations. Two, just synchronize the RandomAccessFile object. However, after carefully analysis, now I have some questions about my design, which ars as follows:
As mentioned above, every clinet thread can only obtain the same remote object instance through RMI. And the remothe object instance has a static instance of Data class. That means each client can access the physical data file only through the same instance of Data class and RandomAccessFile object. Thus, no matter I chose to synchronize the methods of Data class or RandomAccessFile object, if there is a client thread which is implmenting a database action, read or write db file, other client threads have to wait untill that client thread ends its action. On another word, suppose now there are 300 client threads connect to RMI server, at a time point, only one client thread can performes its database action, no matter it's a read or write action, all of the left client threads have to wait to obtain the chance.
I think it probably produce performandce problem to respond quickly to client's request. What I want is all the client threads can read db file simultaniously as long as no client thread performe write actions. Of course, if a client is perform write action in db file, all the other clients have to wait.
Could someone give your favourable suggestions? Thanks in advance!

Robert Huang

[Robert Huang]

Hello all,
I am waiting for answer for this post and no one yet replied.
Can Ken Krebs、Andrew Monkhouse and Bill Robertson or other kind people throw your light on my question?
Thanks very much!
Robert

[Andrew Monkhouse]

Hi Robert,
Welcome to JavaRanch.

I am waiting for answer for this post and no one yet replied.

Please be aware that everyone at this site is coming here voluntarily, and people visit from all over the world. So it is quite reasonable that you might not get an answer within the 3 hours between when posted your original question and when you posted the follow up. For example: yesterday I was only here in the morning (my time) and you did not post until after I had signed off for the day. Please leave a minimum of 24 hours before raising a question a second time (longer on weekends).

I use the singleton design pattern to implement the remote object

Do you actually force the RemoteDataImpl to be a Singleton, or do you simply create a single instance of it?
I would advise against forcing a Singleton - for what you want the same results can be achieved by only instantiating a single instance of the class. And you have no way of knowing whether sometime in the future someone may want to have multiple instances of that class.

originally, I have two choices to implement the synchronize mechanism. One, synchronize all methods of Data class, which are related to database operations. Two, just synchronize the RandomAccessFile object.

Either would work in your situation, however I would recommend that you synchronize at the lowest level that is possible. For example the following two code snippets do the same job, but one will potentially give better performance as the synchronization block is smaller:

  synchronized readARecord() {
      seekToFileLocation
      readInBytes
      converBytesToStrings
  }
  readARecord() {
      synchronized(this) {
          seekToFileLocation
          readInBytes
      }
      converBytesToStrings
  }

I think it probably produce performandce problem to respond quickly to client's request.

Yes, there is a potential for a bottleneck here. The question is whether this is going to cause enough of a problem for you to want to fix it - the reading will be very quick. But see below...

What I want is all the client threads can read db file simultaniously as long as no client thread performe write actions. Of course, if a client is perform write action in db file, all the other clients have to wait.

No matter how you do this, you are going to end up with a single point where everything has to be synchronized. The question is - how far are you willing to go to reduce that issue?
You could simply accept that this is going to happen: document it, and don't spend too much time on it
Or you could try having multiple instances of your random access file - then only synchronize on the actual read or write (this can lead to other issues though).
Or you could store all the records in a cache - this is probably going to give you the best performance of the lot.
What option would you like to explore?
Regards, Andrew

[Robert Huang]

Hi,Andrew
Thanks for your reply.

Do you actually force the RemoteDataImpl to be a Singleton, or do you simply create a single instance of it?

Yes, I do actually force the RemoteDataImpl to be a Singleton. The instance of RemoteDataImpl can only be obtained through call a method of RemotheDataImpl class( static public RemoteDataServer getInstance(String database) )

I would advise against forcing a Singleton - for what you want the same results can be achieved by only instantiating a single instance of the class. And you have no way of knowing whether sometime in the future someone may want to have multiple instances of that class.

It seems reasonable. I'll consider your suggestion. Maybe I should force the Data to be a Singleton instead of RemoteDataImpl. Thus each client's requests(read,search,update)can only be performed through the same instance of Data class. Andrew,How do you think about this thought.

Either would work in your situation, however I would recommend that you synchronize at the lowest level that is possible.

Accept! I understand your suggestion is synchronize in the smallest scope, thus all client threads can make influence upon each other in a short time.
Thus, I think synchronize the RAF object is better than synchronize methods of Data class. Is it right?

You could simply accept that this is going to happen: document it, and don't spend too much time on it
Or you could try having multiple instances of your random access file - then only synchronize on the actual read or write (this can lead to other issues though).
Or you could store all the records in a cache - this is probably going to give you the best performance of the lot.

I don't want to have multiple instances of RAF, because I think there probably lies some issues when multiple instance of RAF access the same physical db file simultaneously, such as the location of file pointer or dirty read.
As for having a cache in Data class to store all the records, I think it can solve the problem about reading simultaneously. But, it occupy the memory and increase the complexity. For example, the cache should be guaranteed to have the latest data. That means the cache should be updated after updating/writing a record in db file, and it also should be synchronized during the write action(lock->check->process->unlock)to avoid dirty read. On other side, if a client thread want to perform a write action when some threads are reading this cache, whether all the threads(read)have to wait untill the thread(write) finish its action and update the cache or this thread(write) can perform its action only after all the threads(read)have finished their actions. Andrew,how do you think my consideration?
Thus, I think I should have a test to find whether the bottleneck of system performance need to be fixed when the read actions can't be performed simultaneously. If it is really a big problem, I think I have to have a cache in Data class to store all the records. But it should be carefully designed.
Thanks again,
Robert