Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

RMI, threads, locking unlocking records

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I am in a delimma. Some facts
1. The assignment says that concurrent use of the database when booking flights from multiple clients should be provided. This means that concurrent access of different records from multiple clients has to be provided.
This implies that the methods in the Data implementation class on the server side cannot be synchronized. Otherwise concurrent access would not be possible.
2. The remote method request from each client to the server object is going to be as a seperate thread (most likely it is going to be from a different JVM and as per the RMI specs calls originating from different client virtual machines will execute in different threads).
This implies that the Data class on the server side needs to be made thread safe. How do we do that ?
Lets take one of the methods getRecord(int rec) . Lets say the first client wants to get the 5th record. He has to seek to the 5th record and then read it. The second client at the same time wants to read the 10th record. So he has to seek to the 10th record and then read it. If the method getRecord(int rec) is not synchronized it is possible between the time the first client seeks to the 5th record and starts reading it, the second client seeks to the 10th record. This causes the first client to read the 10th record insead of the 5th that he was supposed to. from the above arguemnt it seems that the method getRecord(int rec) needs to be synchronized.
Now I am in a delimma from discussion at (1) I conclude do not synchronize the methods while from discussion at (2) I conclude synchronize the methods.
Could anyone help me in removing my delimma.
For some time I felt that for each request by the client a new instance of the server side object (implementation of Data) is created and hence the seeks of one request is unrelated to the seeks of the other. But now I feel that only one instance of the server side object exists. That object is created by the server class which provides the Data service. Multiple instances of proxies (stub) to the server side object is created.
thanks in advance
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am in a delimma. Some facts
1. The assignment says that concurrent use of the database when booking flights from multiple clients should be provided. This means that concurrent access of different records from multiple clients has to be provided.
This implies that the methods in the Data implementation class on the server side cannot be synchronized. Otherwise concurrent access would not be possible.
THAT'S CORRECT. THE DATA IMPLEMENTATION CLASS OR THE REMOTE CLIENT WILL NOT HAVE SYNCHRONIZED METHODS.
2. The remote method request from each client to the server object is going to be as a seperate thread (most likely it is going to be from a different JVM and as per the RMI specs calls originating from different client virtual machines will execute in different threads).
This implies that the Data class on the server side needs to be made thread safe. How do we do that ?
IF YOU OBSERVE, THE DATA CLASS IS THREAD-SAFE AS ALREADY MOST OF IT'S DATA MODIFYING METHODS ARE synchronized, which is necessary.
Lets take one of the methods getRecord(int rec) . Lets say the first client wants to get the 5th record. He has to seek to the 5th record and then read it. The second client at the same time wants to read the 10th record. So he has to seek to the 10th record and then read it. If the method getRecord(int rec) is not synchronized it is possible between the time the first client seeks to the 5th record and starts reading it, the second client seeks to the 10th record. This causes the first client to read the 10th record insead of the 5th that he was supposed to. from the above arguemnt it seems that the method getRecord(int rec) needs to be synchronized.
getRecord(int) is already synchronized and needs to be as u have pointed out above.
Now I am in a delimma from discussion at (1) I conclude do not synchronize the methods while from discussion at (2) I conclude synchronize the methods.
-> The Remote Client part will not have synchronized methods to facilitate concurrent transactions but, the Data class already has sync methods which, I feel should not be changed.
Could anyone help me in removing my delimma.
For some time I felt that for each request by the client a new instance of the server side object (implementation of Data) is created and hence the seeks of one request is unrelated to the seeks of the other. But now I feel that only one instance of the server side object exists. That object is created by the server class which provides the Data service. Multiple instances of proxies (stub) to the server side object is created.
I AM NOT COMPLETELY SURE, BUT, I FEEL THERE IS ONLY ONE REMOTE OBJECT AND ALL THE CLIENT THREADS GET IS A REFERENCE VIA THE CLIENT-SIDE STUB. The stub is on the client side and thus would be 1 per remote object. So, There will not be multiple instances of the stub.
Hope this helps.
Ashwin.
thanks in advance
 
Happiness is not a goal ... it's a by-product of a life well lived - Eleanor Roosevelt. Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic