Win a copy of The Way of the Web Tester: A Beginner's Guide to Automating Tests this week in the Testing forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Synchronization Granularity

Erin Bierer
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From reading the synchronization threads, I�ve seen people sync at many different levels:
1.) Synchronize all public record accessing/modifying methods of their Data class.
2.) Sync on an inner class or member of Data (i.e. a record cache or wrapper obj).
3.) Perform multiple obj sync using a lock map then a single record to update/modify.
However, I haven�t seen an answer to my problem. I was in camp #1, but moved towards #2 (I think the junior programmers can now understand a bit more efficient sync scope ). I�ve modified my record manipulation methods to do something similar to the following:

My concern is now that all �public synchronized� methods have been replaced with just �public�, do I have a synchronization issue with ? The exportRecord method is private to Data, but is not sync�d on anything. I just trust that all record modifying methods call in a sync block that is synchronized on the record cache (which they do since I wrote it that way). So all file I/O is performed in a synchronous manner. My initial unit test for methods that do this sort of thing (delete, update, create, etc.) seem to indicate that it is OK. It should work, but is it acceptable? One new mod/call to update a record outside the sync block and its over. Can someone offer any input? Thanks.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic