Tibor17 commented on a change in pull request #65:
URL: https://github.com/apache/maven-resolver/pull/65#discussion_r457495658
##########
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultSyncContextFactory.java
##########
@@ -28,31 +30,59 @@
import org.eclipse.aether.artifact.Artifact;
import org.eclipse.aether.impl.SyncContextFactory;
import org.eclipse.aether.metadata.Metadata;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.inject.Singleton;
/**
- * A factory to create synchronization contexts. This default implementation
actually does not provide any real
- * synchronization but merely completes the repository system.
+ * A factory to create synchronization contexts. This default implementation
uses fair global locking
+ * based on {@link ReentrantReadWriteLock}. Explicit artifacts and metadata
passed are ignored.
*/
@Named
+@Singleton
public class DefaultSyncContextFactory
implements SyncContextFactory
{
+ private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(
true );
public SyncContext newInstance( RepositorySystemSession session, boolean
shared )
{
- return new DefaultSyncContext();
+ return new DefaultSyncContext( shared ? lock.readLock() :
lock.writeLock(), shared );
}
static class DefaultSyncContext
implements SyncContext
{
+ private static final Logger LOGGER = LoggerFactory.getLogger(
DefaultSyncContext.class );
+
+ private final Lock lock;
+ private final boolean shared;
+ private int lockHoldCount;
+
+ DefaultSyncContext( Lock lock, boolean shared )
+ {
+ this.lock = lock;
+ this.shared = shared;
+ }
public void acquire( Collection<? extends Artifact> artifact,
Collection<? extends Metadata> metadata )
{
+ LOGGER.trace( "Acquiring global {} lock (currently held: {})",
+ shared ? "read" : "write", lockHoldCount );
+ lock.lock();
Review comment:
@michael-o
Can you explain the concept of clocking critical sections with read and
write lock separately? We are downloading and writing a file. Writing a stream
on the disk must be treated by the write lock because it is exclusive lock.
Where is the read lock used and why? I guess this issue is about locking the
writes to the disk from one JVM but two or more threads.
Additionally, the fairness must not be taken as any functionality. No logic
must rely on any fairness.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
