オブジェクトを以降のリクエストでも、他の利用者にも使えるようにすること。
ページを以降のリクエストや他の利用者からも使えるようにすること。
永続化するものはページくらいしかない。
- -
永続化でやること †
- Fetch
キー(複数) → オブジェクト(複数) - Store
キーとオブジェクト → 保存できていたらそのキー/さもなくば「保存できなかった」という何か - Search
何か → 適合するキー(複数)
何かとは…キーの一部 または永続化クラスが特別視する部分…例えばクラス名とか。 - ValidateKeys
キー(複数) → 使えるキー(複数)
永続化クラス内部で使われるので、呼び出し側が使う必要は無い。
Storeせずに使えるキーを得るために。
永続化は後付けで †
例えば…
Search→Fetch
組み合わせて使う。
永続化での上書きは追加で †
同一キーの書き込みはファイルの追加。ファイル追加ならロック待ちがおきないので効率的。
古いファイルは残す。同じキーに関連付けられるオブジェクトは複数。
:i/永続化での上書きは追加で †
上書き時、古いファイルは残す。
ファイル名に時刻でも付ければいい。新しいファイル名として有効ならいい。排他的ロックをかけられるまでは残す。
:i/永続化での削除も追加で †
参照可能なのは最新版。
1つのキーに対して複数のファイルが存在するので、最新版は探して見つける。ファイル名探索。
古いファイルは消せるときに消す †
古いファイル(同一キーでより新しいファイルがあるというファイル)を消すのはいつでもいい。消せるときに。
つまり最新版でなくて排他的ロックを取得できたファイルは消していい。
:i/永続化でのキー変更も追加で †
永続化キーの変更は編集であり削除でもある。
これもロック不要。負担にならない。
データベースとの関連付け †
:i/古いファイルは消せるときに消す †
排他的ロック/共有ロック †
排他的ロックを使うのはファイルを作るときと消すときだけ。
変更/上書きはしないのでN/A。
共有ロックを使うのはファイルを参照するとき。
:i/排他的ロック/共有ロック †
ファイルを消すときだけブロック(ロック待ち)が発生しうる。
:i/ロックシステム †
ロックは全てロックシステム[?]を守らなければならない。
永続化のキー †
Validateで削除か置き換えになる文字がある。
ファイルシステムのパスに使えない文字。
→全て永続化クラスで。ロックシステムは必要ない。
:i/永続化のキー †
ディレクトリ区切りはそのままディレクトリ区切りになる。
ファイルシステムを直接見たときに分かりやすいように。
【パスの形式】 永続化ディレクトリ/クラス名/キー(ディレクトリ区切りがあればそれをディレクトリとして扱う).time.拡張子
Store時、渡されたキーが使えるキーでなければ勝手に変更する。ValidateKeysを使って。
Storeではキーが渡されなくてもいい。勝手に生成する。
戻り値に実際に使ったキーを含める。
シリアライズ †
Store時、シリアライズ可能なオブジェクトを渡されたらそのシリアライズを実行。不可能ならToString()でもしておく。それも不可能ならエラー。渡すオブジェクトはいずれかができなければならない。
(Stringのシリアライズは不要。Stringのシリアル形式はString)
:i/永続化クラスでの検索 †
検索機能とは別の、低いレベルの話。
効率化 †
永続化クラスでの検索 †
検索機能とは別の、低いレベルの話。
キューイング †
読み書きジョブをキュー入れ/キュー出し。
永続化を使う側の一つ。永続化からすると使われ方の例。
永続化システムはロックとパフォーマンス低下を防ぐ方法。
※通常の編集1回で1回のロックとファイル削除が必要。でもすぐにでなくていい。やることの分散。編集時のロックをいつでもいいようにしてパフォーマンス低下防止。しかもロックは非ブロックですぐタイムアウトにしていい。待たない。
:i/キューはModelに出すもの †
キューイング †
†キューはModelに出すもの
†キューの永続化
:i/キューの永続化 †
全体複製をしたくないなら †
ちょっと更新するだけで全体を複製することになる。そこで時間がかかるなら逆効果。
全複製は1ファイルで1エントリー全体をまかなえるということ。複数ファイルで1エントリーだったら?
→関連ファイルを全て読み込んでマージすればいい。この場合エントリーに追記するだけなら複製不要。参照は新しい順に、エントリー1つ分が揃うまで、ファイル参照をして、得たデータを全てマージ。
型によってはマージ不可能。その場合は全複製を要する。条件が多すぎて使いにくい。
それよりも1エントリーをDictionaryの1エントリーに見立てて、フォルダーをDictionaryにすればいい。
フォルダーをネストすればDictionaryのネストのようになる。キー→キー→値といったアクセスが可能に。
:/内部名と外部名 †
これをどう記録して参照を速くするか。
†:i/ページ名インデックス
フォルダーをDictionaryとして使う方法で。
問題 †
:Done/参照したときすでに古いかも †
編集の衝突判定から書き込みまでロックが必要。
方法は…
衝突判定のあと何もしないかも知れないので、ファイルを作ったりはしないで。
それでいて他のプロセスと共有できる方法は…
既存ファイルのロック。
そのファイルとは…
ロック用ファイル。同一キーのtimeなし。キーごとに常設だけど無くてもいい。初回使用時に作る。存在確認が面倒ならキー作成時に一緒に作っておく。キー削除時、一緒に消す。
ファイル間のバージョンがずれる †
ファイル間でバージョンのずれがあり得るので、複数ファイルを同時に更新しても読んだときにいずれかが古いままの可能性がある。
依存関係のあるデータは1つのエントリーにする。
待たされるのを覚悟で最新版を要求することはできる。