あき
attin****@kk*****
2006年 2月 10日 (金) 16:37:14 JST
あきです。 > 竹添です。 > > まず、ページの更新と、問題になっているダウンロードカウンタ > では更新頻度が大きく異なるという前提があります。 なるほど。この前提は考慮に値するかもしれません。 > ページの読み込みについては仰るように、更新時にリネームするという > 対応（そのうえで更新ロックに失敗したらdieする）でよいと思います。 > もちろん、厳密にはこれではダメですが、更新頻度とのバランスを考えた > ときに、この方法がよいのではということです。 > > これはDefaultStorage.pmの中での話ですね。 はい、それで良いと思います。 > 一方で、Util.pmが提供する設定ファイルの読み書き用のAPIについては > > ・読み込みだけなら従来のload_config_xxxx（ロックなし） > ・書き込みだけなら従来のsave_config_xxxx（ロックあり） > ・読み込んだ値を元に新しい値を書き込むなら新しい関数 > > というような使い分けをするイメージです。 > > ここで、save_config_xxxxや新規関数でページと同じくリネーム方式を採用 > すれば（ページの更新と違ってロック取得失敗時のリトライは必要でしょうが）、 > 読み込みに関しても問題ないでしょう。そのうえでダウンロードカウンタの > ように読み込み→書き込みを1トランザクションで実行したい場合は新しい > 関数を使えばよいということになります。 そうですね。 カウンタに関しては読み書きが一瞬で終わりますので、（というより、読み書き のロジックが１箇所でまとまりがよい、ということの方が大きい）ので、切り 分けて考えて良いかもしれません。 > やはりダウンロードカウンタでは正確な値が知りたいと思うのと、すでに値が > 消えるという状況が頻発している状況で更新のみにロックをかけても、ファイル > が壊れることはないかもしれませんが、かなりの確率で古いデータで上書き > されてしまうことが目に見えてますよね。 う〜ん。「かなりの確率で…」というのは問題を過大に見積られている気がしま す。 現状のシステムでカウンタが頻繁にクリアされてしまうのは、全添付ファイルの カウンタが一つのファイルで管理されているからですよね。（添付ファイル毎に カウンタ管理用のファイルも分けられていれば、衝突が発生する確率は格段に低 く抑えらているはず） かつ、衝突が発生した場合に、全情報がクリアされてしまうところが問題を大き くしてしまっている原因です。 書き込み中ファイルの読み込みを回避できれば、たとえ衝突が起きたとしても 影響があるのはその対象の添付ファイルのカウンタのみです。かつ、カウンタが ０になるのではなく、カウントアップしないだけですので、大した問題ではない と思います。 （現状だと、２人のユーザが、それぞれ異なる添付ファイルを同時にダウンロー ドしただけで、全ダウンロードカウンタが０にクリアされてしまいますが、別名 保存→リネームにした場合は、同時にダウンロードされようとした一方の添付 ファイルのダウンロードカウンタだけがインクリメントされないだけとなります） 決して確率は高くないと思います。 一つの案として、単に衝突が起きないようにカウントアップさせることだけが 目的でしたら、１添付ファイル１ファイルで管理するようにして、カウントアッ プはファイルの内容を書き換えるのではなく、追記書き込みモードで任意の文字 （通常は改行コード）を1byte出力するようにする方法もあります。 現在のカウントを取得するにはファイルの内容を読み込むのではなく、ファイル サイズを取得するのです。 このようにすれば、破壊される心配はありません。 私は以前、アクセスカウンタをこのようにして管理してました。 ご参考まで…。 > ただ、Util.pmの設定ファイル読み書き用APIは、あくまで設定ファイルの読み > 書きを行うもので、もともとダウンロードカウンタのように頻繁に更新が発生 > するケースでの使用は想定していませんでした。ですので読み書きロックに > 関してはUtil.pmではなく、ダウンロードカウンタのプラグイン内部で自前で > 行うといった整理はありえると思います。 はい、状況が異なりますので、別でもよいと思います。 ただ、同様のプラグインを自前で作成する方のためにも、排他制御に関する部分 だけはAPI化しておいた方が良いと思います。 > > もちろん、簡単に対応できるならそうすべきですが、ちょっと考えただけでも > > 肥大化してしまいそうですよね？ > > コーディングコストと成果のバランスは是非とも大切にして頂きたく…。 > > 肥大化というのはちょっとわからないです。どういうことでしょうか。 すみません。分かりにくかったですね。 これは私の個人的な拘りでもあるのですが、私は、ソースのボリュームと機能の ボリューム（完成度を含む）のバランスをとても大切に考えています。 簡単に言いますと、最小限のステップ数で最大限の効果を提供したい、と…。 そこに技術者としての誇りを感じていたい、と思っています。 そういった意味では、徹底的に構造化設計されたFSWikiはとても綺麗なアプリケ ーションだと感じています。 安全機能を極めるのもいいですが、その恩恵以上に無駄にソースが複雑になるな ら、私としては「あまり嬉しくないかな」って思ってます。 もちろん、改造コード量に見合う効果があるならその限りではありません。 > あと、flockに関してですが、特定のレンタルサーバで使えないケースが > あります。そもそもそういうサーバでFSWikiが動くのかはわかりませんし、 > そこまで考慮する必要はないのかもしれませんが…。 なるほど…。 使えないサーバもあるのですね。
Fork