#?SuikaWiki/0.9

[1]
前から考えていた構造のキャッシュ化を実験しているのですが、思ったほどの効果がありません。

[[SuikaWiki/0.9]] の出力で一番経費が高いのは text -> XML object ではなく XML object -> HTML の転写なので、前者を少々改善したところで後者があるのであまり意味が無いのかもしれません。

HTML 化したものをキャッシュできればよいのですが、そうすると糞ブラウザ対策や l10n ができなくなります。

HTML 化の部分は XSLT 対応ブラウザにはクライアント側でやってもらうという手もありますが。
([[名無しさん]] [WEAK[2004-04-24 03:39:23 +00:00]])

[2]
ところでまたもやロックの問題があるのでメモ。

キャッシュという性質上、当然書込みの必要が出てきます。さて、 WikiForm のように部分修正して本体 DB に書込む処理の場合、元の木がキャッシュにあればそれを使いたいのですが、その時にはキャッシュにある木が壊れていない保証が必要です。キャッシュのデータが壊れないためにはロックしないといけません。

というわけでキャッシュ DB 全体で排他ロックしてしまうと、同時アクセスできなくなりますから処理効率が下がります。
そうなるとどうなるかは書くまでも無いでしょう。

対策:
- DB を局所的にロック
- 書込み用データ取得にはキャッシュを使わない
- キャッシュの整合性検査

([[名無しさん]] [WEAK[2004-04-24 03:47:44 +00:00]])

[3]
SuikaWiki::DB::Logical::WithStruct (今思えば Logical ってなんか変な名前だ) の使い方メモ:
- [VAR[p]] に本体 (直列化データ) DB を、 [VAR[p]]__struct_cache にキャッシュ (構造化データ) DB を束縛しておく
- 本体データを得る時:
== 普通に [VAR[p]] で get。
- 構造化データを得る時:
== [VAR[p]] で get。この時引数にオプション struct=>1 を与える。
== undef が返ってきたらキャッシュ無し。
元データから作る。
- 本体データを保存する時:
== 普通に [VAR[p]] に set。
- 構造化データを保存する時:
== あらかじめ対応する本体データを保存しておく。
== 構造化データを [VAR[p]]]], struct=>1 で set。
- その他の操作 (keys, exist, delete) は struct=>1 の有無で対象が切り替わる。

get の内部:
- 本体データが求められていれば [VAR[p]] から get
- 構造化データが求められていれば [VAR[p]]__struct_cache から get して、
content_id を見て本体データとの齟齬をチェック。無問題なら返し、違っていればキャッシュを削除して undef を返す。

set の内部:
- 本体データを set するときは、 [VAR[p]] に set し、 [VAR[p]]__struct_cache を削除。
- 構造化データを set するときは、
[VAR[p]]__struct_cache に set。

本体 DB にはメソッド _content_id が必要。
このメソッドは与えられた key のデータの識別子を返す。この識別子はキャッシュとの整合性検査のもので、データのハッシュなど、なんでもいいが、セッションを超えて持続しないと意味が無い。

キャッシュ DB にはハッシュ参照を保存する。 ->{content_id} は上述の content_id 値。 ->{value} には実際の値。
(外部から見えるのは value だけ。)

([[名無しさん]] [WEAK[2004-04-24 04:00:06 +00:00]])


[4]
メタ情報保存用の SuikaWiki::DB::FileSystem::LeafProp を作ってみました。
LeafFile をちょっといじるだけですぐにできちゃいました。

これを使って内容の[[媒体型]]を指定する仕組みの、編集用 UI 
のところも作ってみました。 Edit mode で select が出ているのが分かると思います。

肝心のそれを書きこむ側の機能はまだ実装していません。
正規化や安全の問題があるのでどうするか少し考えてみます。


([[名無しさん]] [WEAK[2004-04-24 06:49:41 +00:00]])