Skip to content

Add N5Reader.readShard and N5Writer.writeShard - #201

Closed
bogovicj wants to merge 19 commits into
developmentfrom
feat/read-write-shard
Closed

Add N5Reader.readShard and N5Writer.writeShard#201
bogovicj wants to merge 19 commits into
developmentfrom
feat/read-write-shard

Conversation

@bogovicj

Copy link
Copy Markdown
Contributor

And a few tests.

see #196

tpietzsch and others added 12 commits January 21, 2026 21:30
The existing deleteBlock() loads the DatasetAttributes and calls this
new variant.
Add default implementation of N5writer.writeRegion
* multiple read locks can be held across threads
* only a single write lock can be held
* still to do: holding a read lock does not prevent writing

see #141
refactor: FileKeyLockManager is a static singleton now, and more KeyLockState logic is package-private
Signed-off-by: Caleb Hulbert <cmhulbert@gmail.com>
Locks are not tied to the locking thread anymore. (A LockedChannel can be
created by one thread and then be released by another thread). This required to
replace ReentrantReadWriteLock with manual reader/writer counting guarded by
Semaphores.

LockedFileChannel is now created by KeyLockState (instead of FileKeyLockManager)
because for releasing we need to distinguish between read and write locks.

I revised clean-up of stale KeyLockStates by putting WeakReferences in the
ConcurrentHashMap and adding a ReferenceQueue to remove entries whose
KeyLockState has been GCed.

I put no special logic to handle leaked LockedFileChannels (that are abandoned
without being properly closed). Surprisingly, this still works. When the
KeyLockState is GCed, its associated ChannelLock along with the existing
FileChannel and FileLock is also GCed. At least on MacOS, this causes the JVM to
release the system-level lock, and everything works out fine.
…nnel

This fixes behaviour on Windows, where the we cannot open another
FileChannel on the write-locked path. We have to use the channel that we
locked.
@bogovicj
bogovicj changed the base branch from master to development January 28, 2026 01:00
@bogovicj
bogovicj marked this pull request as ready for review January 30, 2026 19:51
@bogovicj

bogovicj commented Jan 30, 2026

Copy link
Copy Markdown
Contributor Author

Want to highlight this commit 6add658

that addresses an issue that came up during shard deletion.
When deleting one block that is part of a shard, the shard needs to be read so that the data for other blocks can be re-written.

At this time, we need to ensure that this reading happens before a write lock is acquired, hence the fix in the commit above.

We may need to revisit this after #202

* rather return, leaving the request's blocks as null
* test a list of nulls is returned for non-existing blocks
* test number of backend read calls for readBlocks
@bogovicj

Copy link
Copy Markdown
Contributor Author

these commits were merged by #203

@bogovicj bogovicj closed this Feb 11, 2026
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