Description
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.
Attachments
Attachments
Issue Links
- fixes
-
MNG-5838 Maven on No-File-Lock Systems
-
- Closed
-
- relates to
-
MRESOLVER-177 Move pre-/post-processing of metadata from ResolveTask to DefaultMetadataResolver
-
- Closed
-
- supercedes
-
MRESOLVER-68 Add caching around File.getCanonicalPath
-
- Closed
-
- links to