[#se4e36a8]アクセスカウンタがリセットされてしまう。Database等を使ってリセットされないようなオプションを用意する。[#fbc22beb]Database等を使ってリセットされないようなオプションを用意する。SQLiteがPHP5.1で組み込まれているので利用しやすい。するとDB利用カウンタになる。[#x5f6e3c0]ファイル利用カウンタのデータをデータベース上のデータに変換するツールです。counterプラインのオプションとして、カウンタをSQLiteのDBで保持するようにしました。現行のcounterの排他処理はちゃんと記述されているように見えましたが、Modify処理(ftruncate→fputs)がアトミックではないので何らかの理由でサーバー側のプロセスが異常終了するとカウンタが消失してしまうということでしょうか。コメントありがとうございます。正直なところ、カウンタがリセットされる原因がはっきりわかっているわけではないです。[[BugTrack/191]]も解決済みになっています。このサイトのトップページでもでもたびたびリセットが発生しています(ここのバックエンドはNFSだと思われます)し、私の運用しているサイトでも発生します。flock自体が信頼できない環境ですか。それを想定するなら、ファイルベースではmkdir(やsymlink)を使ったファイルロックを自前で実装するしか無いかもしれませんね。ロック解除待ちでポーリングが必要、プロセス異常終了時にロックディレクトリが残ってしまう対策などがあるので、できれば今更使いたくはないところですが。更新処理を「一時ファイル生成→Rename」にすれば、書き込みがアトミックになるので多少は問題が緩和するかもしれません。(カウント前とカウント後のどちらかの値は読めるので0リセットは起こらなくなる。従来のcounterは「排他ロック→Read→Modify(+1)→Write→アンロック」という排他制御がされています。SQLite版のcounterは排他制御が不十分で、「Read→Modify→Write」の間に他のアクセスが割り込むとそのアクセスではWriteする前の値をReadしてしまいます。その結果、カウント数が実アクセス数より少なくなる恐れがあります。&br;EXCLUSIVEトランザクションを使えば問題は解決できると思いますが、SQLiteは行ロックが無くデータベース全体のロックになること、Wikiページ全てで1つのデータベースを共有する構成であることからパフォーマンス面で懸念があります。鋭いご指摘ありがとうございます。それほど厳密なカウントでなく、またご指摘のように過剰なロックでパフォーマンスが落ちてしまうことを避けるために、多少の誤差には目をつぶることにしました。(リセットされてしまうよりはマシ、ということです)。ことにすれば、既存処理と同程度の精度にはなりますね。表示する値とのズレを気にしていたのですが、表示の方がずれても問題は少ないということに気が付きました。UPDATE時+1は良いですね。カウンタ100の時に3人が同時アクセスすると3人ともカウンタ100を見ることにはなりますが、カウンタは103までまわるので、大局的には問題が無いです。カウンタがリセットされるぐらいflockが期待通りに動かない環境ならSQLiteのトランザクションも期待できないことに気づきました。見ると、「NFS上のロックに見られるようにロック実装自体に問題があるとデータベースは壊れる」ようなことが書かれているので、そういう環境だとだめそうですね......。flockはカウンタだけでなくページ編集などでも使われているので、flockが動かない環境まで考慮する必要があるならカウンタ以外にも影響が出そうです。