On 09/09/2013, at 5:21 AM, Daz DeBoer <darrell.deb...@gradleware.com> wrote:
> G'day > Since we're currently changing the way we manage locks in the Gradle cache, > it would be great if we could separate the 'filestore' part of the cache > (that hasn't changed in structure since 1.0) from the binary metadata part > (which changes quite frequently). > > What this means is that we'd have these in separate directories: > ~/.gradle/caches/metadata-1 > ~/.gradle/caches/filestore-1 > > The 'filestore' would simply contain the content that is currently in > caches/artifacts-n/filestore. > > The benefit of this change is that the actual downloaded files would not need > to be copied into a new location every time we change the metadata file > format. > > The only complication I see is that we'd need a separate (cross-version) lock > for the filestore since it would be shared by different Gradle versions. We'd > need to bump the filestore version whenever the locking mechanism changes, > rather than every time the metadata store format changes. I think having two locks would make it easy to deadlock when there are 2 processes (or threads) resolving concurrently. We could address this by enforcing a certain lock order (eg always lock the files if you need to lock the metadata). Another option would be to have a single lock for both the files and metadata, versioned on the locking protocol, something like: ~/.gradle/caches/files-1 ~/.gradle/caches/files-1/store-1 ~/.gradle/caches/files-1/metadata-1 Where the lock is on ~/.gradle/caches/files-1 `files-1` is incremented when the locking protocol changes. `store-1` is incremented when the file store layout changes. `metadata-1` is incremented when the metadata layout changes. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle eXchange 2013, Oct 28th in London, UK: http://skillsmatter.com/event/java-jee/gradle-exchange-2013
