多重送信防止処理の実行結果
組み込んだ多重送信防止処理の実行結果を見てみましょう。
実行前は次のように場所が登録されていないとします。
図7：実行前
［1］多重送信防止なし
まず、今回の多重送信防止を組み込む前の結果を見てみましょう。
1度目の追加処理が終わる前にもう一度追加ボタンをクリックした場合、2回追加処理が行われてしまいます。今回は同じ名前による重複チェックなどを行っていないため、同じ場所が2つ登録されてしまいました。
図8：多重送信防止なし
［2］多重送信防止あり
多重送信防止を組み込んだ後に同じように実行した場合、次のようにエラーメッセージが表示されます。
図9：多重送信防止あり
この状態ではこの後何度追加ボタンを押しても、追加処理は行われず、同じエラーメッセージが表示されます。
場所検索画面に戻ると2度目の追加処理がキャンセルされたことが確認できます。
図10：追加処理キャンセルの確認
なお、多重送信防止の動作はリスト3の「新たなトークンの発行」の後に、以下のようにスリープ処理を入れると簡単に確認できます。
リスト4 テスト用のスリープ処理
// トークンが一致するか判定
if (vsToken == sToken)
{
// 一致
// 新たなトークンの発行
var newToken = GenerateToken();
Session["LocationsAdd_Token"] = newToken;
ViewState["LocationsAdd_Token"] = newToken;
// テスト用スリープ処理
System.Threading.Thread.Sleep(3000);
}
まとめ
ASP.NET Webフォームアプリケーションでの状態管理方法のポイントは、以下のとおりです。
- ASP.NET Webフォームアプリケーションには、有効期間と保持範囲が違う状態管理法が用意されているので、ケースに応じて適切に使い分ける。
-
複数ページにまたがる状態をはじめ、状態は基本的にSessionに保存する。
- Sessionはサーバーのリソースを消費するので、あまりに大きなデータは保存せず、不要になったらすぐにクリアする。
- Sessionのセッション状態モードの「インプロセス」は運用環境では使用せず、ステートサービスかデータベースを使用する。
-
ViewStateは基本的にはサーバーコントロールによって自動的に設定される値がほとんどであり、明示的に使うケースはそれほど多くない。
- EnableViewStateプロパティ、ViewStateModeプロパティを活用し、ViewStateが不要なコントロールではViewStateを無効にする。
- ViewStateはhidden項目を使ってクライアントサイドとやり取りされるため、大きなデータや機密性の高いデータは保存しない。
- ViewStateとSessionを組み合わせることで、ワンタイムトークンを用いた多重送信防止といった処理も、比較的簡単に実装できる。
さて、次回はデータを更新する際のトランザクション制御と排他処理について紹介する予定です。次回もお楽しみに。
