- - PR -
Application.Lockの動作について
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2005-11-17 17:28
ほ、ほんとですか?それはないと思いますが… と思ったけど明確に記述されてるドキュメントがいまいち見あたりませんね… 実際の動作は、 Lock、UnlockでMonitor辺りを使ったロックと解除 それに加えて、Application変数アクセス時は内部的に自動的にLock、Unlockを実行している、というイメージだと思うんですが。 ところで、UnlockはTry Finallyを使ってFinallyで実行するようにしたほうがいいですよ(やってるかもしれませんが)。 個人的には、Application.Lockはあまり使うべきでないと思います。 例えば今回の同期はDBに関する同期なわけですが、Application.Lockは対象を指定できません。 この場合、DBアクセスの同期のために、他のすべてのApplication変数へのアクセスが待たされることになります。 ※ロックの範囲は適切に限定するべきという話です。 --追記 Webサーバを分散しているときなんかは言わずもがなですが、 Webガーデンを使っているときや、たとえ使っていなくてもタイミングによっては、 Application.Lockでは完全な同期ができない可能性があることも意識しておいたほうがよいです。 ※同期したい対象が「Application変数自体」であれば別ですが。 [ メッセージ編集済み 編集者: なちゃ 編集日時 2005-11-17 17:32 ] | ||||
|
投稿日時: 2005-11-17 21:10
■途中報告です。
とりあえず、ASP.NETとASPで アプリケーション変数を使用しないプログラムを作成して動かしてみました。 まだ、十分な検証が済んだワケではありませんが、 ASP.NETとASP共に、なちゃ様が仰るように アプリケーション変数を使用しなくても排他制御が行われているようです。 以下のような動作(動作1)で、期待する動作でした。 ▼動作1 ========================================= A B --------------------------------------- ↓ | ロック 待機 ↓ | 排他したい処理中 | (一意ID取得) | ↓ | ロック解除 ↓ ↓ ロック 次の別処理へ ↓ 排他したい処理中 (一意ID取得) ↓ ロック解除 ↓ 次の別処理へ ========================================= >個人的には、Application.Lockはあまり使うべきでないと思います。 >例えば今回の同期はDBに関する同期なわけですが、Application.Lockは対象を指定できません。 なちゃ様のご指摘の通り、DBが軸となる処理の場合は、 トランザクション+SET LOCK_TIMEOUT…WITH(ROWLOCK, UPDLOCK) を使用して制御した方がいいかもしれませんね。 元々、投稿したきっかけは、 ASPで開発していた時に以下の動作(動作2)をしたような 記憶があったので、ASP.NETでは違うのかな?と疑問に思ったので 投稿した次第です。 (初回の投稿で上手く伝えられずに申し訳有りません) ▼動作2 ========================================= A B --------------------------------------- ↓ ↓ ロック 待機 ↓ | 排他したい処理中 | (一意ID取得) | ↓ | ロック解除 ↓ | ロック | ↓ | 排他したい処理中 | (一意ID取得) | ↓ (何故か待機) ロック解除 ↓ ↓ 次の別処理へ 次の別処理へ ※Bがロック解除するまで、Aが待機している ========================================= 今回、ASPのテストプログラムを作ってみたのですが、再現できませんでした。 (かなり古い開発のためオリジナルソースは見つからず) ASPでも「動作1」の動作をしたので 私の記憶違いか、当時のプログラムの記述がマズかったのかも知れないのですが どなたか「動作2」の現象を見たことはないでしょうか? [ メッセージ編集済み 編集者: sakusaku 編集日時 2005-11-17 21:13 ] |