File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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

Win a copy of The Software Craftsman this week in the Agile forum!
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.
Have you tried LearnNowOnline?
subject: Synchronization Granularity