Naoki Takezoe
takez****@gmail*****
2006年 2月 10日 (金) 17:17:41 JST
竹添です。 06/02/10 に あき<attin****@kk*****> さんは書きました: > > やはりダウンロードカウンタでは正確な値が知りたいと思うのと、すでに値が > > 消えるという状況が頻発している状況で更新のみにロックをかけても、ファイル > > が壊れることはないかもしれませんが、かなりの確率で古いデータで上書き > > されてしまうことが目に見えてますよね。 > > う〜ん。「かなりの確率で…」というのは問題を過大に見積られている気がしま > す。 > 現状のシステムでカウンタが頻繁にクリアされてしまうのは、全添付ファイルの > カウンタが一つのファイルで管理されているからですよね。（添付ファイル毎に > カウンタ管理用のファイルも分けられていれば、衝突が発生する確率は格段に低 > く抑えらているはず） > かつ、衝突が発生した場合に、全情報がクリアされてしまうところが問題を大き > くしてしまっている原因です。 > 書き込み中ファイルの読み込みを回避できれば、たとえ衝突が起きたとしても > 影響があるのはその対象の添付ファイルのカウンタのみです。かつ、カウンタが > ０になるのではなく、カウントアップしないだけですので、大した問題ではない > と思います。 > （現状だと、２人のユーザが、それぞれ異なる添付ファイルを同時にダウンロー > ドしただけで、全ダウンロードカウンタが０にクリアされてしまいますが、別名 > 保存→リネームにした場合は、同時にダウンロードされようとした一方の添付 > ファイルのダウンロードカウンタだけがインクリメントされないだけとなります） > 決して確率は高くないと思います。 インクリメントされないか、全ての値がクリアされるかという現象の違いは ありますが、現象が発生する確率は同じじゃないですか？ 確かに問題の重大さという点では全然違ってきますが、後述するように対応 すること自体はそんなに難しいことではないですし、プラグイン開発者にしても 別に嫌なら使わなければいいわけで、同期更新用の関数があってもそんなに 害はないでしょう。 > 一つの案として、単に衝突が起きないようにカウントアップさせることだけが > 目的でしたら、１添付ファイル１ファイルで管理するようにして、カウントアッ > プはファイルの内容を書き換えるのではなく、追記書き込みモードで任意の文字 > （通常は改行コード）を1byte出力するようにする方法もあります。 > 現在のカウントを取得するにはファイルの内容を読み込むのではなく、ファイル > サイズを取得するのです。 > このようにすれば、破壊される心配はありません。 > 私は以前、アクセスカウンタをこのようにして管理してました。 > ご参考まで…。 もともとはこういう実装じゃなくて添付ファイルのダウンロードログ （これは追記モードで書き込んでいます）をサマリしてダウンロード数を 計算していたのですが、要望があって単一ファイルに記録するように したんですよね。まあ、単一ファイルならバックアップも取りやすいですし Util.pmの関数経由で取得できるので扱いやすいし、ということで。 > > ただ、Util.pmの設定ファイル読み書き用APIは、あくまで設定ファイルの読み > > 書きを行うもので、もともとダウンロードカウンタのように頻繁に更新が発生 > > するケースでの使用は想定していませんでした。ですので読み書きロックに > > 関してはUtil.pmではなく、ダウンロードカウンタのプラグイン内部で自前で > > 行うといった整理はありえると思います。 > > はい、状況が異なりますので、別でもよいと思います。 > ただ、同様のプラグインを自前で作成する方のためにも、排他制御に関する部分 > だけはAPI化しておいた方が良いと思います。 まぁ、他のプラグインからも使えるようにするならやはりUtil.pmですかね。 > > > もちろん、簡単に対応できるならそうすべきですが、ちょっと考えただけでも > > > 肥大化してしまいそうですよね？ > > > コーディングコストと成果のバランスは是非とも大切にして頂きたく…。 > > > > 肥大化というのはちょっとわからないです。どういうことでしょうか。 > > すみません。分かりにくかったですね。 > これは私の個人的な拘りでもあるのですが、私は、ソースのボリュームと機能の > ボリューム（完成度を含む）のバランスをとても大切に考えています。 > 簡単に言いますと、最小限のステップ数で最大限の効果を提供したい、と…。 > そこに技術者としての誇りを感じていたい、と思っています。 そんなに複雑にはならないんじゃないかと。 新しい関数を追加するだけでコアには影響ありませんし。 sub sync_update_config(ファイル名, 関数リファレンス){ 1)ロック 2)ファイルから読み込み 3)読み込んだ値を引数として関数を呼び出し 4)戻り値を一時ファイルに書き込み 5)リネームしてロック解除 } みたいな感じで。 > そういった意味では、徹底的に構造化設計されたFSWikiはとても綺麗なアプリケ > ーションだと感じています。 > 安全機能を極めるのもいいですが、その恩恵以上に無駄にソースが複雑になるな > ら、私としては「あまり嬉しくないかな」って思ってます。 > もちろん、改造コード量に見合う効果があるならその限りではありません。 いやいや、現在3.5のコアには過去のしがらみとかで無駄に複雑な 部分が結構ありますよ。 ただ、この関数については用途も意義もあると思ってます。 -- Naoki Takezoe <takez****@gmail*****>
Fork