synchronization best practices.

[Jeremy Botha]

Hi, all.

I'm in the process of unit testing my data access classes prior to moving on to networking and UI design. One thing I'm thinking hard about is which methods in the data access class require locking.

Obviously, update and delete require it. Create too, to prevent the possible double-use of a record ID. However, I'm not convinced that read and search require it, mainly since

a) these operations will be performed more frequently than the prior three and thus locking all pertinent records might have a debilitating effect on concurrent access to the system
b) read and find do not directly modify the data.

From my experience with 'real' db servers (and I may be horribly wrong here) select does not wait while background updates and inserts occur; if it did the database would be functionally unusable.

Does anyone disagree with this?

Thanks for taking the time to read.
Jeremy

[Edwin Dalorzo]

Hi, Jeremy.

I have working on the implementation of the database these days before. I myself faced a few questions and I simply took the decisions I considered more appropriate and documented them in the choices.txt file.

Now, I started simple, I began by implementing the DBAccess interface provided by Sun within the assignment specification.

In my case neither the readRecord() nor the findByCriteria() methods offered any possibility of locking a record. Conversely, the update and delete method signatures pass a lockCookie as parameter, indicating that the record must have been lock prior to the change operation.

While I was implementing the interface, I discovered how likely it is that while one client is updating a record, another one could be reading it.

As far as I understand the Sun specification does not contain any information in this regard. Nevertheless, I decided to implement a transaction isolation mechanism apart from that offered by the record locking.

In my case I registered every transaction in progress. During a read transaction over a particular record, no further change transaction are accepted until the read is complete. On the other hand, I accept multiple read transactions over the same record. Finally, while a change transaction is being performed, any read transactions over the record have to wait until the changes are completed.

I reduced code synchronization at the minimum possible, and this transaction isolation mechanism does not prevent other read or update operations, in independent records, to happen.

I am using different locks and conditions for either the record locking mechanism and the transaction isolation. Also, in order to guarantee that transactions are performed in the order they were issued I use a ReentrantLock with fairness set to true.

Nevertheless, I cannot assure the performance of my approach. I have just run a few tests on a very small file with very few client threads.

I would appreciate any comments on this regard also.

I hope this somehow helps.
[ July 19, 2006: Message edited by: Edwin Dalorzo ]

[Mihai Radulescu]

Hi, People

Edwin, your solution only has only half coverage, even if your transactions are isolated (until here you are covered) the way how your read/search results are used (by your implementationor by future extensions) can not be isolated.
What I mean ? Let's say that you search record and you find it , so you and your transaction, and you try to display it somehow - during this process the record content can be altered.
What is really important (IMHO) is that the database file operations are done synchronized.

Regards M.
[ July 20, 2006: Message edited by: Mihai Radulescu ]

[Edwin Dalorzo]

Hello, Mihai

Thanks for sharing your ideas with us.

You are completely right. After having read the record, there is no way I can assure the record was not modified by another client.

For instance, if I query the database to retrieve all the hotels whose name is "Grand View", it could find several records. Let's say there are three of them. While going over every record, previously read records could change. That means that, at the end of my query, the results that I receive could have changed in the database.

In a case like this, prior to the update operation I should check if the record has been changed by another client after I read it. However, this concurrency problem is present even in real RDBMS, and I feel is out of the scope of this assignment. I think I will do nothing to prevent it in this application.

However, I think I should document this issue in the choices.txt file, just to set it clear that I did not implement anything. Thanks for raising this issue.

Regards,
Edwin Dalorzo.