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.dumpsper 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.