@IT会議室は、ITエンジニアに特化した質問・回答コミュニティ「QA@IT」に生まれ変わりました。ぜひご利用ください。
- PR -

Application.Lockの動作について

投稿者投稿内容
sakusaku
会議室デビュー日: 2005/11/16
投稿数: 15
投稿日時: 2005-11-16 21:41
はじめまして。
ASP.NETでWEBサイトの開発をしています。

Application.Lockの動作について気になる事がありましたので
投稿させて頂きます。

以下の処理で複数のユーザがアクセスし、実行したとします。
Application.Lock()をかけて、排他制御を行います。
==========================
Application.Lock()
 <排他したい処理(一意のID発行など)>
Application.UnLock()
==========================
流れとしては、下記となります。
先に実行されてたユーザをA
後に実行されて待機するユーザをB
とします。
1:Aの処理時にロック。
2:Aの処理中は、Bは待機。
3:Aの処理が終わり、ロック解除
4:Bの処理時にロック。
5:Bの処理が終わり、ロック解除

Aが開放されるのは、Bの処理が完了した後と思っていたのですが
実際は、Bが処理中でも、Aは開放される事を確認しました。
(上記プログラムにて、一行毎に日時をResponse.writeで書き出して処理時間を確認)
ASPの時は、Aは処理後もBの処理が終わるまで待って
AB同時に終了(開放)される動作だったと記憶しています。

この辺の動作について、確認できる文献・情報がありましたら
よろしくお願いいたします。

■参照
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpguide/html/cpconapplicationstate.asp

■環境
OS:Windows 2000 sp4
IIS 5.0
Visual Studio 2002
Framework 1.0

[ メッセージ編集済み 編集者: sakusaku 編集日時 2005-11-16 21:41 ]
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-11-16 22:41
引用:

sakusakuさんの書き込み (2005-11-16 21:41) より:

Aが開放されるのは、Bの処理が完了した後と思っていたのですが
実際は、Bが処理中でも、Aは開放される事を確認しました。


この開放の意味が判りかねるので、的を得ない回答になるかもしれませんが、
リファレンスにもあるように、Application.Lock メソッドは、
任意のアプリケーション状態の変数のアクセスをブロックするだけですよね?
Application 変数、static 変数、Cache オブジェクトなどを、
「開放」と言われている処理で参照していなければ、処理は先に進むのではないでしょうか?
どのような処理を開放と呼んでいますでしょうか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
sakusaku
会議室デビュー日: 2005/11/16
投稿数: 15
投稿日時: 2005-11-17 10:37
じゃんぬねっと様
ご返信ありがとうございます。

言葉たらずで済みません。
「開放」は、プログラム的に行う処理ではなく
(ロック→ID発行→ロック解除)の一連の処理が終了し、
次の別の処理を行える状態を意味していました。

>リファレンスにもあるように、Application.Lock メソッドは、
>任意のアプリケーション状態の変数のアクセスをブロックするだけですよね?
はい。
ただ、今回の処理ではDBから一意のIDを発行する処理(取得値に1加算して書込)に使っていました。
そもそも、アプリケーション変数以外に使用するのが間違いなのでしょうか?

>「開放」と言われている処理で参照していなければ、処理は先に進むのではないでしょうか?
はい。実際に.NETでテストプログラムを組んで実行してみると、先に進みました。

昔、ASP(インタプリタ)で開発していた時に、Aは処理が終了しても先に進めず
Bの処理が終わるまでAは待っていてBの処理が終わると次に進める。という動作を
していたような記憶がありましたので、動作の違いが気になりました。

ただ、私の記憶違いかもしれませんので、ASPでのテストプログラムを
組んでみて、改めて投稿させて頂きます。
どっとねっとふぁん
ぬし
会議室デビュー日: 2005/02/23
投稿数: 935
投稿日時: 2005-11-17 10:52
> Application.Lock()
>  <排他したい処理(一意のID発行など)>
> Application.UnLock()

これだけだとロックかからなかったはずですね。
Lockの後にアプリケーション変数にアクセスしにいったときにはじめてロックされたはずです。
なので、ダミーのアプリケーション変数を一つつくって、そこに何か適当な値でもいれてみたらいいんじゃないでしょうか。
このあたりの動作はASPでも同じように動いていたと思います。

sakusaku
会議室デビュー日: 2005/11/16
投稿数: 15
投稿日時: 2005-11-17 11:17
どっとねっとふぁん様
情報ありがとうございます。

ダミーのアプリケーション変数を使用した場合のプログラムもテストしてみます。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-11-17 11:17
引用:

sakusakuさんの書き込み (2005-11-17 10:37) より:

ただ、今回の処理ではDBから一意のIDを発行する処理(取得値に1加算して書込)に使っていました。
そもそも、アプリケーション変数以外に使用するのが間違いなのでしょうか?


うーん、いわゆる「採番」か何かですよね。
DB ならばデータベース側で排他ロックしても良いですね。

引用:

はい。実際に.NETでテストプログラムを組んで実行してみると、先に進みました。


ですので、小野@どっとねっとふぁんさんが仰るように、
DB での採番処理に使うのであれば、ダミーのアプリケーション状態の変数を使いましょう。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2005-11-17 13:07
昔の ASP の時代の時に使ったことがありますが、Application.Lock/Unlock って変な仕様で分かりにくいですね。ロックの範囲も広すぎますし、今の ASP.NET の時代であえて使う必要はあるのでしょうか。
なお、DB を排他的にアクセスすることが目的ならば、Application を Lock するのではなく、DB のトランザクションで管理したほうが自然ではないでしょうか。もっとも DB が Application に従属することが確かならば、Application で制御しても良いとは思います。
sakusaku
会議室デビュー日: 2005/11/16
投稿数: 15
投稿日時: 2005-11-17 14:34
unibon様
ご指摘ありがとうございます。

今回、投稿させて頂いた件で、最も知りたかった内容は
排他制御の方法ではなく、Application.Lock/Unlockを使用した際の
各ユーザの動作について知りたかったのです。
(はじめに明記しておくべきででした。皆様の混乱を招くような記述で申し訳ありませんでした


テストプログラムの結果と共に
ちょっと、まとめ直して投稿しようと思います。

スキルアップ/キャリアアップ(JOB@IT)