Table of Contents

Namespace OptunaSharp.Storages.Journal

Classes

BaseJournalBackend

Base class for Journal storages. Port of optuna/storages/journal/_base.py: BaseJournalBackend.

Storage classes implementing this base class must guarantee process safety. This means, multiple processes might concurrently call ReadLogs(int) and AppendLogs(IReadOnlyList<OrderedDict<string, object?>>). If the backend storage does not internally support mutual exclusion mechanisms, such as locks, you might want to use JournalFileSymlinkLock or JournalFileOpenLock for creating a critical section.

BaseJournalFileLock

Port of BaseJournalFileLock.

BaseJournalLogStorage

Deprecated alias of BaseJournalBackend.

JournalFileBackend

File storage class for Journal log backend. Port of optuna/storages/journal/_file.py: JournalFileBackend.

The on-disk format is JSON-lines (one compact-separator json.dumps per line, \n-terminated, UTF-8) — byte-compatible with Python Optuna, so a journal file written by either side can be continued by the other with no external dependency on either side (the plan's Tier N cross-language persistence claim).

JournalFileOpenLock

Lock class for synchronizing processes for NFSv3 or later. Port of JournalFileOpenLock.

On acquiring the lock, the lock file is created with exclusive-create semantics (O_CREAT | O_EXCL). The file is deleted when the lock is released. This is the recommended lock on Windows.

JournalFileStorage

Deprecated alias of JournalFileBackend.

JournalFileSymlinkLock

Lock class for synchronizing processes for NFSv2 or later. Port of JournalFileSymlinkLock.

On acquiring the lock, a symbolic link is created for an exclusive file. The file is deleted when the lock is released. In NFS environments prior to NFSv3, use this instead of JournalFileOpenLock. On Windows without symlink privileges, use JournalFileOpenLock. Passed explicitly, this lock fails there, as Python's does; a JournalFileBackend built without a lock switches to the open-file protocol by itself.

JournalStorage

Storage class for Journal storage backend. Port of optuna/storages/journal/_storage.py: JournalStorage.

Journal storage writes a record of every operation to the database as it is executed and at the same time, keeps a latest snapshot of the database in-memory. If the database crashes for any reason, the storage can re-establish the contents in memory by replaying the operations stored from the beginning.

Interfaces

IBaseJournalSnapshot

Optional base interface for Journal storages. Port of BaseJournalSnapshot (a mixin class in Python; an interface in C#).

Storage classes implementing this may work faster when constructing the internal state from the large amount of logs.

IJournalSnapshotInterval

A snapshot-capable journal backend that tells JournalStorage how many study or trial ids apart to save a replay snapshot when the caller does not choose. OptunaSharp only: Optuna snapshots every 100 ids whatever the backend, and has no such interface.

Enums

JournalOperation

Journal operation codes — Optuna's on-disk values.