I have been reading this forum for the last few months but this is my first time posting here. I have a problem and I� am hoping someone can give me some advice.
For the database part of my project I have a DataAdapter and a Data class. The DataAdapter does the locking and unlocking for clients and has a reference to a data object for accessing the database file.
The DataAdapter has a method called getRecordsUsingCriteria() that returns a list of records matching a supplied criteria. getRecordsUsingCriteria() calls the find() method in Data to get an array of record numbers that matches the criteria. Using the record numbers, getRecordsUsingCriteria() reads each record and adds it to a list which is returned to the client.
The find method in Data locks the file while it is searching record numbers. However the getRecordsUsingCriteria() does no locking. I think there is a possibility of a dirty read in the getRecordsUsingCriteria() method, if in between the time getRecordsUsingCriteria() receives the array of records and reads the records another client cuts in an changes the records.
I was wondering what is the best way to avoid this situation. I could either make getRecordsUsingCriteria() synchronized or call synchronized on the Data object and hold the lock for the duration of the method. Which one would be the best solution and would it work?
There are several ways to handle dirty reads like you described.
You could synchronize on the Data object, but this would seriously cut down on your concurrency. I would not recommend this solution.
You could also implement some type of read lock functionality. This is probably outside the scope of the assignment, although I have heard of several people doing it.
You could do secondary checking in your DataAdapter class on the record numbers you get back from the Data object. I think this is a pretty common approach. It also helps with the problem of the "exact match" vs "starts with" discrepancy between the interface provided and the GUI instructions. Your secondary search would have to check each record to make sure it has not been deleted or changed in such a way to make the match invalid. The drawback to this is that there is a performance hit when using the search function.
Whatever you decide, make sure you document it in your choices.txt. Also, just a side note, it sounds like your DataAdapter class is actually implementing more of a Facade pattern than Adapter..
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook