あき
attin****@kk*****
2006年 2月 10日 (金) 10:42:30 JST
あきです。 > 竹添です。 > > 実装としてはページの作成・更新時にロックを取得できなかったらdieする、という > ようなレベルでとりあえずは良いのではと思います。 先のメールのとおり、書き込み時だけのロックでは駄目ですね。 いつ読まれても完全なデータであることを保証する必要はあると思います。 > > と言うわけで、一番簡単な方法は読み込み時にもロックを掛けるというものです > > が、このロックは排他ロックのみですので、使用頻度が高いload_config_textに > > それをやってしまうとパフォーマンス低下が無視できなくなる気がします。 > > あと、厳密にやるのであれば、読み込みと書き込みに対して別々にロックを > かけるのではなく、読み込み→書き込みという一連の操作に対してロックを > かけないとダメですね。 一時的に別ファイルに出力してクローズ後にリネームなら、（少し古い情報を 読み込む、といった可能性は有るにせよ、）壊れた内容を読み込む、といった 大ダメージは防げると思います > > そこで、「一部のみ更新する」という関数を新規に作って、それを使うようにし > > た方が良いと思います。 > > Util.pmに追加することになると思いますが、どんなインターフェースがいい > んでしょうねぇ。値の読み込み→書き込みに対してロックをかけるとなると、 > すぐに思いつくのは現在の値のハッシュを受け取って、更新済みのハッシュ > を返すような関数のリファレンスを渡す方法とかですが…。 > > とりあえず上書きされちゃってもファイルが破壊されなければいいということ > であれば加藤さんの仰るように一部のみ更新する関数でもよさそうですが、 > どうせやるなら、やはり正しい値を保障できる方法がいいですよね。 「どうせやるなら…」の案に関しては、私も竹添殿が仰っているような対策が 必要なのかな、と思います。 ですが、「そこまで堅牢なシステムでなければならないのか？」と考えると、 それはちょっと首をかしげてしまう部分もあります。 個人的には、「ファイルが破壊されなければいい」という考えで十分な気がし ます。 もちろん、簡単に対応できるならそうすべきですが、ちょっと考えただけでも 肥大化してしまいそうですよね？ コーディングコストと成果のバランスは是非とも大切にして頂きたく…。
Fork