Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
ReadDatareturned byKeyValueAccess.createReadDataare nowClosableVolatileReadData.For
FileSystemKeyValueAccess, theVolatileReadDataholds a (read) lock onto its underlyingFileChanneluntil it is closed. All usages ofKeyValueAccess.createReadDatahave been revised to use try-with-resources to make sure allVolatileReadDataare properly closed after use.The
LazyReadinterface has moved to its own file and is now also responsible for implementing theReadData.prefetchfunctionality (optional, currently does nothing).The
ReadDataimplementation that wrapsLazyReadis now namedLazyReadData(instead ofKeyValueAccessReadData) and was moved to thereaddatapackage.There was a previous
LazyReadDataclass that is now calledLazyGeneratedReadData(and it is fed by aReadData.Generatorinstead of aReadData.OutputStreamWritert).The new
LazyReadDataimplementsVolatileReadDataand forwardsclose()to its delegateLazyReadIn
DefaultDatasetAccess, we avoid preemptively materializingReadDatato check whether a given key exists. Instead, we work with theVolatileReadDataand appropriately handleN5NoSuchKeyExceptionwhen this is (later) thrown when working withLazyReadDatafor non-existing keys.We also make sure to materialize
modifiedReadDataeverywhere if write-locks would overlap withexistingReadDatalocks.