Naoki Takezoe
takez****@gmail*****
2006年 2月 10日 (金) 12:29:31 JST
竹添です。 06/02/10 に あき<attin****@kk*****> さんは書きました: > あきです。 > > > 竹添です。 > > > > 実装としてはページの作成・更新時にロックを取得できなかったらdieする、という > > ようなレベルでとりあえずは良いのではと思います。 > > 先のメールのとおり、書き込み時だけのロックでは駄目ですね。 > いつ読まれても完全なデータであることを保証する必要はあると思います。 まず、ページの更新と、問題になっているダウンロードカウンタ では更新頻度が大きく異なるという前提があります。 ページの読み込みについては仰るように、更新時にリネームするという 対応（そのうえで更新ロックに失敗したらdieする）でよいと思います。 もちろん、厳密にはこれではダメですが、更新頻度とのバランスを考えた ときに、この方法がよいのではということです。 これはDefaultStorage.pmの中での話ですね。 > > > と言うわけで、一番簡単な方法は読み込み時にもロックを掛けるというものです > > > が、このロックは排他ロックのみですので、使用頻度が高いload_config_textに > > > それをやってしまうとパフォーマンス低下が無視できなくなる気がします。 > > > > あと、厳密にやるのであれば、読み込みと書き込みに対して別々にロックを > > かけるのではなく、読み込み→書き込みという一連の操作に対してロックを > > かけないとダメですね。 > > 一時的に別ファイルに出力してクローズ後にリネームなら、（少し古い情報を > 読み込む、といった可能性は有るにせよ、）壊れた内容を読み込む、といった > 大ダメージは防げると思います > > > > そこで、「一部のみ更新する」という関数を新規に作って、それを使うようにし > > > た方が良いと思います。 > > > > Util.pmに追加することになると思いますが、どんなインターフェースがいい > > んでしょうねぇ。値の読み込み→書き込みに対してロックをかけるとなると、 > > すぐに思いつくのは現在の値のハッシュを受け取って、更新済みのハッシュ > > を返すような関数のリファレンスを渡す方法とかですが…。 > > > > とりあえず上書きされちゃってもファイルが破壊されなければいいということ > > であれば加藤さんの仰るように一部のみ更新する関数でもよさそうですが、 > > どうせやるなら、やはり正しい値を保障できる方法がいいですよね。 > > 「どうせやるなら…」の案に関しては、私も竹添殿が仰っているような対策が > 必要なのかな、と思います。 > ですが、「そこまで堅牢なシステムでなければならないのか？」と考えると、 > それはちょっと首をかしげてしまう部分もあります。 > 個人的には、「ファイルが破壊されなければいい」という考えで十分な気がし > ます。 一方で、Util.pmが提供する設定ファイルの読み書き用のAPIについては ・読み込みだけなら従来のload_config_xxxx（ロックなし） ・書き込みだけなら従来のsave_config_xxxx（ロックあり） ・読み込んだ値を元に新しい値を書き込むなら新しい関数 というような使い分けをするイメージです。 ここで、save_config_xxxxや新規関数でページと同じくリネーム方式を採用 すれば（ページの更新と違ってロック取得失敗時のリトライは必要でしょうが）、 読み込みに関しても問題ないでしょう。そのうえでダウンロードカウンタの ように読み込み→書き込みを1トランザクションで実行したい場合は新しい 関数を使えばよいということになります。 やはりダウンロードカウンタでは正確な値が知りたいと思うのと、すでに値が 消えるという状況が頻発している状況で更新のみにロックをかけても、ファイル が壊れることはないかもしれませんが、かなりの確率で古いデータで上書き されてしまうことが目に見えてますよね。 ただ、Util.pmの設定ファイル読み書き用APIは、あくまで設定ファイルの読み 書きを行うもので、もともとダウンロードカウンタのように頻繁に更新が発生 するケースでの使用は想定していませんでした。ですので読み書きロックに 関してはUtil.pmではなく、ダウンロードカウンタのプラグイン内部で自前で 行うといった整理はありえると思います。 > もちろん、簡単に対応できるならそうすべきですが、ちょっと考えただけでも > 肥大化してしまいそうですよね？ > コーディングコストと成果のバランスは是非とも大切にして頂きたく…。 肥大化というのはちょっとわからないです。どういうことでしょうか。 あと、flockに関してですが、特定のレンタルサーバで使えないケースが あります。そもそもそういうサーバでFSWikiが動くのかはわかりませんし、 そこまで考慮する必要はないのかもしれませんが…。 -- Naoki Takezoe <takez****@gmail*****>
Fork