Skip to content

Conversation

@tpietzsch
Copy link
Collaborator

The ReadData returned by KeyValueAccess.createReadData are now Closable VolatileReadData.
For FileSystemKeyValueAccess, the VolatileReadData holds a (read) lock onto its underlying FileChannel until it is closed. All usages of KeyValueAccess.createReadData have been revised to use try-with-resources to make sure all VolatileReadData are properly closed after use.

The LazyRead interface has moved to its own file and is now also responsible for implementing the ReadData.prefetch functionality (optional, currently does nothing).

The ReadData implementation that wraps LazyRead is now named LazyReadData (instead of KeyValueAccessReadData) and was moved to the readdata package.
There was a previous LazyReadData class that is now called LazyGeneratedReadData (and it is fed by a ReadData.Generator instead of a ReadData.OutputStreamWritert).
The new LazyReadData implements VolatileReadData and forwards close() to its delegate LazyRead

In DefaultDatasetAccess, we avoid preemptively materializing ReadData to check whether a given key exists. Instead, we work with the VolatileReadData and appropriately handle N5NoSuchKeyException when this is (later) thrown when working with LazyReadData for non-existing keys.
We also make sure to materialize modifiedReadData everywhere if write-locks would overlap with existingReadData locks.

tpietzsch and others added 9 commits February 2, 2026 22:26
...because we will need the LazyReadData name for the ReadData that
wraps LazyRead.
VolatileReadData is Closable.

LazyRead is now also Closable.

The VolatileReadData implementation LazyReadData closes its delegate
LazyRead when it is closed. The file-system FileLazyRead locks the path
it refers to on construction and holds the lock until it is closed (via
a wrapping LazyReadData).

All usages of KVA.createReadData have been revised to use
try-with-resources to make sure VolatileReadData are properly closed.

DefaultDatasetAccess has been revised to not eagerly materialize
ReadData. This is in preparation of using partial loading and
prefetching. (This is a separate topic, not necessary for using
VolatileReadData correctly, but was too difficult to disentangle in the
git history after the fact...)
* test a list of nulls is returned for non-existing blocks
* test number of backend read calls for readBlocks
@cmhulbert
Copy link
Contributor

We should address this before merging (#204 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants