I am a bit unsure about my remote object implementation and wonder whether someone could clarify me a bit.
I did not use Remote Factory and only have one object of my DBServicesRemoteImpl registered with RMI. I believe when multiple clients request they all will get a reference to this same DBServicesRemote Impl object.
In side this class I have book and search implemented. This class gets singleton instance of Data class to handle all low level db file operations and all methods in the Data class are synchronized.
However, I feel this is not enough and I probably also need to synchronize my DBservicesRemoteImpl methods. The reason being:
for example, my book(Contractor, custID) method in the remote object will need to lock, update and unlock the record. If I don't synchronize the whole book method or the Data instance, then there could be several clients calling the book at the same time and get messy state. For example,
client A calls book and just done lock
client B calls book and is locking another record
client A then calls update which now that the values such as contractor and customer id are different because client B is calling the same book method.
This would surely mess my data update even though all Data methods are synchronized. I have a lot of checks to make sure data are intact but I think that is not enough. I think I should synchronize the whole book and search methods in my remote impl in order to get atomic result. Am I right?
My Data class looks same like yours: singleton pattern applied and all methods marked synchronized. I also didn't use the RemoteFactory pattern and had (just like you) 1 object of DBServicesRemoteImpl which was registered in the RMI registry. I didn't synchronized any method of DBServicesRemoteImpl, because that's not necessary, because your Data class is (or should be) already thread-safe.
Local variables like your contractor en custId are always thread-safe.
Originally I thought when each client look up a remote object, the RMI starts a thread for the client and the thread will get a copy of the registered remote object. However, in looking some RMI specifications my original understanding might be incorrect. Those threads are not getting a copy but just a reference to the remote object. Thus the same remote object gets shared by all client.
So multiple client shares the same object and they all call the same method like book(Contractor, custID), won't it mess up? The book() is not synchronized but the called methods in the book() are synchronized.
unlock in finally.
Like thread A called book(contractorA1, custidB1) and just finished lock the record and is about to update. In the mean time, thread B called book(contractorA2, custidB2) and just finished lock too. At this time both thread needs to call update, which contractor and custid are used?
Joined: Apr 27, 2007
Ok. I think I am just messing myself up. My contractor parameter are not shared in the book() call. Each thread has its own contractor object. They won't mess up. Local variables are in stack and won't mess up too. I guess I am a bit over nervous. Time to take a break
1.) Am I right in concluding that I dont need RMI factory since my lock method returns a cookie value and my update, delete and unlock methods accept this cookie value as parameter for client identification?
2.) Since my Data class is thread-safe and my locking does not involve passing a cookie from the client to the server (as you did), I think I dont need any form of synchronization in my remote object?
2/ although I have to make a small remark: even if I didn't pass the client-id from client to server, and just generated one in the book-method I still would need some synchronization in the remote object. I must guarantee that the combination of setting this client-id and locking the record is executed as 1 atomic operation. I need 2 method calls on the Data instance to lock a method, you just need 1.
...I must guarantee that the combination of setting this client-id and locking the record is executed as 1 atomic operation. I need 2 method calls on the Data instance to lock a method, you just need 1.