ASP/ASP.NETでやってはいけないこと
一部地域で話題沸騰中の「岡崎市中央図書館へのクローラーアクセス問題」。高木浩光氏によると一部のソースがあったらしい
http://takagi-hiromitsu.jp/diary/20100821.html#p01
見た瞬間「はぁぁ？」と思ってしまった。が、噂ではよくある実装らしい。
"On Error Resume Next"してErr.Numberをチェックしない
VBだとこのほかに"On Error Goto Hoge"してjava|C#なんかのtry-catchブロックのようなことが出来る(厳密には違う)が、ASP|VBScriptでは文法上許可されていない。従ってちゃんとしたエラー処理を書くには実行時エラーの出そうな部分で"On Error Resume Next"を宣言しておき、文を実行した直後にErr.Numberをチェックしてエラーの有無を確認しなければならない。しかし、どういうわけか"On Error Resume Next"が「エラーを無視する魔法の方法」と思われている節があり、まともにエラー処理をしてない例がよくある。
確かに1行ごとに If Err.Number<>0 Thenなどと書くのは冗長で面倒なのだが、それでは望む結果は得られないはず。
DBコネクションをSession変数に格納する
「そんなの常識」と格納する派と格納しない派が言う。格納しない派の意見は「コネクションの確保は時間がかかる」なのだが、これはコネクションプールを使えば回避できるはず。コネクションプールを実装していない可哀相なDBドライバを使っている場合はコネクションプールを実装したドライバに切り替えるか、自前で実装する必要がある。
ただ、どちらにしても基本的には「コネクションが必要になったときコネクション確保、使い終わったら破棄」しなければならない。
オラクルを使っている場合に「select for update」して特定の行をロックし、そのロックを「ページ間で|次のPOSTまで」持続したい、なんていう間抜けがいるみたいだがそんなことはやっていられない。やってしまうと他のタスクからのselectにいちいち no waitをつけねばならず、すべてのページのunloadでウェブサーバーに通信してロックを開放するか「まだロックが必要」の場合にロックを持続せねばならず、セッションタイムアウト時に確実にロックを開放できなければならず、etc...と実装しなければならないタスクが爆発的に増えてしまう。
やりたければ論理的なロック機構を実装するとかしたほうが良い。より良いのはロックではなく行のバージョンによる更新可否チェックだと思う。
