jQuery in Action, 3rd edition
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Synchronization Granularity Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Synchronization Granularity" Watch "Synchronization Granularity" New topic

Synchronization Granularity

Erin Bierer

Joined: Jan 18, 2004
Posts: 2
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.
I agree. Here's the link: http://aspose.com/file-tools
subject: Synchronization Granularity
It's not a secret anymore!