Send to your Kindle ***[[:i/キューはModelに出すもの]] [#bca5bab1] RIGHT:[[:t/永続化]] ページを以降のリクエストや他の利用者からも使えるようにすること。 永続化するものはページくらいしかない。 ---- #contents **永続化は後付けで [#k93a286d] ***[[:i/永続化での上書きは追加で]] [#c1313797] ***[[:i/永続化での削除も追加で]] [#xfd6d35b] ***[[:i/永続化でのキー変更も追加で]] [#rf3f140f] 永続化キーの変更は編集であり削除でもある。 これもロック不要。負担にならない。 **データベースとの関連付け [#i39acd2e] ***[[:i/古いファイルは消せるときに消す]] [#aeaf399f] ***[[:i/排他的ロック／共有ロック]] [#j61c0374] ***%%[[:i/ロックシステム]]%% [#z2b10f1d] %%決まった順序でロック。予約制なので必要なロックを事前に決めなければならない。%% %%永続化クラスも同じファイルを読み書きするならこのルールを守らなければならないが、ロック対象と永続化クラスで扱うファイルは区別して対処。例えばディレクトリを分けて。同じファイルを両者で使うことはしない。%% →全て永続化クラスで。ロックシステムは必要ない。 ***[[:i/永続化のキー]] [#md972074] ***[[:i/永続化クラスでの検索]] [#q93c0dda] 検索機能とは別の、低いレベルの話。 RIGHT:[[:t/永続化]] **効率化 [#zcd047fa] ***キューイング [#i54f8bba] RIGHT:[[:t/キュー]] [[:t/開発]] 読み書きジョブをキュー入れ／キュー出し。 永続化を使う側の一つ。永続化からすると使われ方の例。 永続化システムはロックとパフォーマンス低下を防ぐ方法。 ※通常の編集1回で1回のロックとファイル削除が必要。でもすぐにでなくていい。やることの分散。編集時のロックをいつでもいいようにしてパフォーマンス低下防止。しかもロックは非ブロックですぐタイムアウトにしていい。待たない。 ***[[:i/キューはModelに出すもの]] [#bca5bab1] ***[[:i/キューの永続化]] [#ab6061b1] ***全体複製をしたくないなら [#e7160e07] ちょっと更新するだけで全体を複製することになる。そこで時間がかかるなら逆効果。 全複製は1ファイルで1エントリー全体をまかなえるということ。複数ファイルで1エントリーだったら？ →関連ファイルを全て読み込んでマージすればいい。この場合エントリーに''追記するだけ''なら複製不要。参照は新しい順に、エントリー1つ分が揃うまで、ファイル参照をして、得たデータを全てマージ。 型によってはマージ不可能。その場合は全複製を要する。条件が多すぎて使いにくい。 それよりも1エントリーをDictionaryの1エントリーに見立てて、フォルダーをDictionaryにすればいい。 フォルダーをネストすればDictionaryのネストのようになる。キー→キー→値といったアクセスが可能に。 ***[[:/内部名と外部名]] [#bcfa0e95] これをどう記録して参照を速くするか。 †[[:i/ページ名インデックス]] フォルダーをDictionaryとして使う方法で。 **問題 [#sf83f730] ***[[:Done/参照したときすでに古いかも]] [#z5f2d514] 編集の衝突判定から書き込みまでロックが必要。 方法は… 衝突判定のあと何もしないかも知れないので、ファイルを作ったりはしないで。 それでいて他のプロセスと共有できる方法は… 既存ファイルのロック。 そのファイルとは… ロック用ファイル。同一キーのtimeなし。キーごとに常設だけど無くてもいい。初回使用時に作る。存在確認が面倒ならキー作成時に一緒に作っておく。キー削除時、一緒に消す。 ***ファイル間のバージョンがずれる [#hc92c1db] ファイル間でバージョンのずれがあり得るので、複数ファイルを同時に更新しても読んだときにいずれかが古いままの可能性がある。 依存関係のあるデータは1つのエントリーにする。 待たされるのを覚悟で最新版を要求することはできる。 **永続化/ [#i3d330bf] - 永続化でやること #ls
