[MRESOLVER-132] Remove synchronization in TrackingFileManager

[jira-importer]

Michael Osipov opened MRESOLVER-132 and commented

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.

---

Affects: 1.5.0

Attachments:

• call-hierarchy-read.png (62.46 kB)
• call-hierarchy-write.png (130.57 kB)

Issue Links:

• MNG-5838 Maven on No-File-Lock Systems
  ("fixes")

• MRESOLVER-177 Move pre-/post-processing of metadata from ResolveTask to DefaultMetadataResolver

• MRESOLVER-68 Add caching around File.getCanonicalPath
  ("supercedes")

Remote Links:

• GitHub Pull Request #67
  

Backported to: 1.6.0

[jira-importer]

Michael Osipov commented

Elliotte Rusty Harold, please have a look at this.

[jira-importer]

Michael Osipov commented

Fixed with fcb6be59c5a5855573886b09c70dab80074a1d27.