Session と Transaction

　今日、１００都市の巡回セールスマン問題デモの挙動を見ていて、はたと気が付きました。
　事前に３００都市の全ての組み合わせの経路とコストを計算してあるので、３００都市分の経路データをＤＢから読み込む時間は、都市数に関係なく定数時間で済みます。また、巡回セールスマン問題を解くルーチンは、１００都市ならば１秒もかからずに計算できるはずなので定数時間と言って差し支えない。にもかかわらず、１０都市で計算させる場合と、３０都市で計算させる場合に明らかに時間が３倍ほど違ってきます。
　ウェブ・サービスの場合、HTTP/1.1 のプロトコルであろうと、セッションを持続する保障はどこにもありません。よって、リクエスト毎にミニマルな SQL 呼び出しを行い、大抵は BEGIN TRANSACTION から COMMIT を省略してしまいがちです。ところが、巡回セールスマン問題を解くルーチンでは、結果をデータベースに一旦保存しているので、１回のストアド・プロシジャ呼び出しに対して、都市数だけ更新が隠れています。TRANSACTION を指定しない場合は、オート・コミット・モードであり、都市数回の COMMIT が実行されているのではないか？って事です。
　ストアド・プロシジャ内で更新をかける場合には、IN TRANSACTION かどうかを調べて、TRANSACTION 外であれば、BEGIN TRANS から COMMIT でサンドイッチするように書いた方が良いのかもしれません。