2005年05月29日に、MagSite1を0.50にバージョンアップしました。
今回のバージョンはいくつか重要な問題への対処を含んでいます。
入手先 §
MagSite1 0.50は、MagSiteMan1上からダウンロードできるほか、MagSiteDistシステムよりダウンロードできます。
MagSite1手動ダウンロード
変更点 §
変更点は以下の通りです。
- アクセスのカウントアップの時、DelayedUpdaterが止まっていることを検知し、警告メールをルートキーワードの管理者に送付
- ソースコードのいくつかの技術的改善
変更点の詳しい説明を以下に述べます。
アクセスのカウントアップの時、DelayedUpdaterが止まっていることを検知し、警告メールをルートキーワードの管理者に送付 §
前バージョンでのアクセスカウント巻き戻り現象の対策が十分ではなかったことが判明したので、別の機能を入れてみました。
どうも誤解されているようなふしもあるので、念のために説明しますが……。
遅延書き込み機構(DelayedUpdater)という機能は、応用プログラムのレベルで明示的に実装している機能です。アクセスカウンタの書き込みを遅延し、かつ、同じファイルへの書き込みリクエストは統合し、かつ、直列化します。つまり、MagSite1のアーキテクチャ的にカウンターのファイル書き込みの負荷が馬鹿にならないので、これを効率化するために用意されたメカニズムです。
そこで問題になるのは、ASP.NETというアーキテクチャは、基本的にユーザーからリクエストがあった時にだけユーザーコードを動かすというアーキテクチャであり、バックグラウンドで待機して遅延書き込みするようなアーキテクチャとは、とてつもなく相性が悪いことです。ASP.NETでのプロセスの管理は、ASP.NET側が勝手に行い、プロセスを勝手に止めたり再起動することもあります。つまり、プロセスの管理がブラックボックス化されています。もう1つ、遅延書き込みはスレッドプールから取得したスレッドで処理されますが、スレッドプールも一種のブラックボックスです。
アクセスカウント巻き戻り現象の問題がこじれているのは、再現条件が不明であるといった問題と合わせて、ASP.NETというブラックボックスの挙動が見切れていない面があることは否めません。少なくとも、ASP.NET上でなければ、同じコードをもっと自信を持って動かすことができます。(実際、ASP.NET上ではなくNUnit上で動かすTDDの単体テストでは問題は起きていない)
さて、ここが本題です。
ならば、できるだけブラックボックスに依存しないアーキテクチャにすれば、問題が解決できるのではないか?と思う人がいるでしょう。
当然です。それは1つの正論です。
しかし、そのような解決手段は、正しくはないと思います。まあ、時間がない時にはそのような対処を行う場合もありますが、現時点でMagSite1はスケジュールを切られた開発プロジェクトではなく、急いではいません。急いではない以上、正しくない対処を取るつもありはありません。
では、なぜ正しくないのか。
アクセスカウント巻き戻り現象には、間違いなく原因が存在します。そして、それは、ある程度の水準まで突き止められるはずです。「真実はいつも1つ」でも「真実はいつも私に微笑む」でも良いですが、名探偵の嘘くさい台詞がこのケースでは正しくなります。つまり、原因は突き止めることができるはずなのです。そして、存在するはずの原因を見過ごすということは、より大きな災厄をもたらす可能性があります。例えば、現時点では「アクセスカウント巻き戻り」という致命的ではない現象しか確認されていませんが、もしかしたら他の致命的な現象に直結するリスクを持った「原因」という可能性もあります。ここで原因を確認しないということは、そのようなリスクに立ち向かうことを放棄することとイコールです。
そして、ここが重要ですが、このような分かりにくい「バグ」に立ち向かい、知力でそれを撃破するというのは、チャレンジする価値がある知的遊戯でもあります。いかにして、疑いようもなく問題を確定するかは、殺人事件の犯人を捜すよりもエキサイティングな推理ゲームです。
ソースコードのいくつかの技術的改善 §
上記問題に関連してソースコードの検討を行ううちに、より好ましいコーディングがあり得る箇所をいくつか発見したので、修正を加えています。