I am headaching on wheather to synchronize my find(String criterion) in my singleton Database class.
If I don't synchronized find(String criterion), any possibility that thread A finish putting all the search record NO into result, then thread B come in and initialize result=null, then thread A would end up with getting a null result on its searching. Correct me if I am wrong.
But if I synchronized find(String criterion), it would end up with nested synchronization. As read(), countTotalRecNo() have been synchronized already.
I guess you are talking about multiple threads here..
Even if two or more threads execute the same method, at the same time, they cannot modify each others local variables as they are independent of each other. Each thread will have its own copy of local variable.
But threads can modify the instance variables of the class at the same time and there needs to be some sync mechanism.
I cannot be sure about what you are doing, but I will share the ideas I came up with when I faced that problem.
First, I simply implemented the DBAccess interface Sun provided me within the assignment specification.
This interface should contain methods like readRecord(long recNo) and findByCriteria(String criteria).
I started by implementing readRecord(recNo) and then I simply reused the method to implement findByCriteria(String criteria).
Stated simply, I go over every record which is not deleted and compare it against the criteria provided. Therefore, findByCriteria(String criteria) reutilizes readRecord(long recNo).
Now, whether you are using RMI or Sockets, you must be very careful with the variables you share in your database implementation. Because, for sure, your database class will be shared between multiple threads when your server is running.
This class has to be able to accept concurrent requests from multiple clients, and while one thread maybe reading a record, it has to be able to be updating another record for another client.
As the rancher in the previous post explained, variables declared locally in a method do not represent a threat for your application, whereas class members variables, either static or non-static, could be potentially accessed by multiple threads at the same time.
For example, if you share the same instance of RandomAccessFile with all the threads, then you are obliged to synchronized any seek operation over the file. Because if while you are reading, another thread asks the database to seek for another record, you would loose the current position, corrupting another thread's read operation.
In this case, an better alternative to synchronizing could be to create new instances of the RandomAccessFile per every transaction avoiding, with this, that two threads search a different record while you are reading or writing with another. This synchronization avoidance will be perceived in the application readiness to accept concurrent transactions.
The same thing may happen with other variables. For instance, when you shutdown your server, it is probable that you will have to turn on a flag indicating that the database is shutting down. This way you will prevent the server from granting new locks to new threads. Since this flag is shared by all the threads using the database server class, you would have to synchronize access to it.
Finally, synchronization is not always the best solution. Since the database server needs to be very responsive and must be always ready to accept new transactions from the clients, you must do an effort to reduce code synchronization at minimum.
Take into account the AtomicClasses in the java.util.concurrent.atomic package and volatile variables for this purposes.
It is better you to get familiar with multithreaded programming before attempting to develop the database server.
I hope this helps! [ July 21, 2006: Message edited by: Edwin Dalorzo ]
an better alternative to synchronizing could be to create new instances of the RandomAccessFile per every transaction avoiding, with this, that two threads search a different record
if two RAF are using the same file you don't know if they do this synchronized or not - this can be platform/JVM/air humidity dependent.
Regards M [ July 24, 2006: Message edited by: Mihai Radulescu ]
SCJP, SCJD, SCWCD, OCPJBCD
Joined: Dec 31, 2004
Hi there, Mihai
I think you are right!
However, I never intended to imply that if you have to instances of RandomAccessFile the access to the underlaying data will be synchronized. As a matter of fact I do not know what the JVM actually does in those cases.
What I meant was that, if you share the same instance of RandomAccessFile with all your threads, and one thread is reading a record while another thread is seeking for a new position into the file, then the read operation will be corrupted because of the pointer relocation, since all the threads are using the same instance of RandomAccessFile.