Uploaded image for project: 'Maven Resolver'
  1. Maven Resolver
  2. MRESOLVER-132

Remove synchronization in TrackingFileManager



    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.0
    • Fix Version/s: 1.6.0, 1.6.1
    • Component/s: Resolver
    • Labels:


      Motivation: The TrackingFileManager is package private, thus never used externally. It uses the interned string reperesentation of the canonical path and file locking. We all know that file locking in a single JVM are pointless, it will lead to race conditions. This is why the locking is multistage. Single JVM and file locks for multi JVM. The interesting part is that if you look up the call stack of TrackingFileManager#read(File) and TrackingFileManager#update(File, Map<String, String>) you'll see that all of them are wrapped in a SyncContext which already adds locks for them. I don't understand why this is done here. If outer lock works, I see no need to lock again somewhere deeper. I am also keen to say that this kind of synchronization can be completely removed if you have a decent SyncContextFactory implementation.
      The TrackingFileManager has been overridden with MRESOLVER-130 and MRESOLVER-131 for obvious reasons.

      In short: the locking (synchronization) has to happen in a sync context, not here. Especially because the canonicalization of paths adds an unnecessary performance penalty.


        1. call-hierarchy-read.png
          62 kB
          Michael Osipov
        2. call-hierarchy-write.png
          131 kB
          Michael Osipov

          Issue Links



              • Assignee:
                michael-o Michael Osipov
                michael-o Michael Osipov
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: