Michael Osipov created MRESOLVER-132:
----------------------------------------
Summary: Remove synchronization in TrackingFileManager
Key: MRESOLVER-132
URL: https://issues.apache.org/jira/browse/MRESOLVER-132
Project: Maven Resolver
Issue Type: Task
Components: resolver
Affects Versions: 1.5.0
Reporter: Michael Osipov
Assignee: Michael Osipov
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.
I am inclined to override the {{TrackingFileManager}} 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
