- PR -

Webアプリについて

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
ichiro
会議室デビュー日: 2004/03/15
投稿数: 12
投稿日時: 2004-03-15 14:26
皆さんすみません抽象的な質問でわからなったですね。

ASP.NETのWebアプリケーションは、マルチタスクですか？という質問です。

「ASP.NETはセッション間が干渉しあわないような仕組みになっていますので」

とありますが、セッション管理について勉強したいのですが、何か参考になる

ものがありましたら教えてください。

詳しく説明しますと、

[Aの画面]
Server.Transfer("../B.aspx?para1=" & para_meta)

[Bの画面]
Request.QueryString("para1")

Aで選択し、Bに遷移します。
Bではpara1をキーにしてデータを１レコード表示させ、
データを修正し、最後に「完了ボタン」で更新を行う。
キーであるpara1の項目も修正するとします。

このような場合には、どうすれば良いのでしょうか？
ユーザA1がAの画面でA1というレコードを選択し、B画面へ。
少し遅れて、ユーザA2がAの画面でA2というレコードを選択し、B画面へ。
ユーザA1で行っているデータは、ユーザA2のデータになってしまうのでは
ないかと思うのですが。。。
このようなことはセッション管理ということになるのでしょうか？
すみません初心者でわからなくて。。。お願いします。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2004-03-15 14:47
NAL-6295です。

http://www.atmarkit.co.jp/fdotnet/aspnet/aspnet15/aspnet15_01.html
あたりが参考になります。

ちなみに内部的には、セッションは要求毎（クライアント毎）に作成されるスレッドの事です。
要求(Request)と返答(Response)は勿論クライアント毎に異なるべきなので、スレッド毎に用意されています。

つまり、各セッション専用なわけですので、上記例のような、A1ユーザとA2ユーザがテレコになるような事はおきません。

あと、マルチタスクですか？という事になると、そうです。という回答になります。

ちなみに、マルチプロセスではなく、マルチスレッドです。

#マルチタスクはNECの登録商標だったけ・・・
#脱線追記：http://www.nec.co.jp/press/ja/0305/2701.html
#によると、「マルチタスクは日本電気株式会社の登録商標です。」だそうです。

[ メッセージ編集済み 編集者: NAL-6295 編集日時 2004-03-15 15:03 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-03-15 14:54
すみません、脱線：
引用:

NAL-6295さんの書き込み (2004-03-15 14:47) より:

#マルチタスクはNECの登録商標だったけ・・・

　え〜〜！そうなの？と、Googleで「マルチタスク」を検索・・・

　登録"商標"ではないが、
http://www.nifty.com/webapp/digitalword/word/069/06902.htm
http://yougo.ascii24.com/gh/11/001116.html
http://ew.hitachi-system.co.jp/w/E3839EE383ABE38381E382BFE382B9E382AF.html

使用は問題がありそうです・・・
http://www.multitask.co.jp/


脱線なので編集で対応：
> #脱線追記：http://www.nec.co.jp/press/ja/0305/2701.html
> #によると、「マルチタスクは日本電気株式会社の登録商標です。」だそうです。
ひぃ〜！えっと、じゃぁ、あの会社って、問題では？？

[ メッセージ編集済み 編集者: Jitta 編集日時 2004-03-16 16:52 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-03-15 15:16
引用:

ichiroさんの書き込み (2004-03-15 14:26) より:

ユーザA1がAの画面でA1というレコードを選択し、B画面へ。
少し遅れて、ユーザA2がAの画面でA2というレコードを選択し、B画面へ。
ユーザA1で行っているデータは、ユーザA2のデータになってしまうのでは
ないかと思うのですが。。。

　時系列に整理して、全部のパターンを説明するのは手間なので、クリティカルなものを１つだけ。

時間の流れ順に、こういう操作になったとする
↓
１．A1がAを表示
２．A1がBに移動
３．A2がAを表示　←　この時点では、データベース中のデータが表示される
４．A2がBに移動　←　ここでユーザA1と同じ画面に移動しても、
　　　　　　　　　　　データベース中のデータが表示されている
５．A2が確定処理　←　ここでキーを変えたとする
６．A1が確定処理　←　ここで「キーがない」エラーになる

１で、A1は「変更しよう」としていますが、５でA2が先に「キー」を変えてしまったため、６で変更しようとするキーがないため、例外的状況になります。

　このことを軽減するために、ADO.NETでは「オプティミスティック同時実行」を選択できます。ややこしい名前ですが、やろうとしていることは「修正するときに、データベース中のデータが取得時と同じか確認し、同じであれば修正を許すが、違うならば例外を生成する」ということです。ただし、ウイザードに任せてこれをすると、すべての列が等しいかどうかをチェックします。列数が多くなると、とても使えたものではありません。

　人間が実装するなら、データベースの排他的ロックを使用します。B画面へ移行するときにテーブル（または行）に読み出し制限をかけ、A2がA画面を表示したときに、変更しようとするキー情報を読み出せなく（結果、選択できないように）します。
　しかし、読み出しも制限してしまうと、他の処理が止まってしまうのではないでしょうか。その場合は、テーブルに「変更予定」カラムを追加します。このカラムに値が入っている場合は、誰かが「変更予定」なので、B画面に遷移できないようにします。
　具体的には、SELECTしてからUPDATEすると、それら２つのコマンドを発行する間にUPDATEされる危険があるため、いきなりUPDATEで、条件として「変更予定」が特定の値の時、を指定します。
例：「UPDATE table SET FLAG=1 WHERE ID=xxx AND FLAG=0」
　　で、戻り値（変更した行の数）が１の時はロックできたとする
これの危険は「デッドロック」と、「ロックしたままいなくなる」です。前者は慎重に設計することで防ぎます。後者は、たとえばB画面に遷移して、B画面をブラウザの「×」ボタンで終了したときなどです。これはセッションの終了イベントでフラグを解放する処理を追加し、軽減させます。

追加：
「戻る」（ブラウザの「戻る」や、ALT+←など）で戻った後、別のキーを選んでB画面に遷移したとき、「戻る」前に指定したキーはロックされたままになります。これも、何らかの方法で回避または処理停止を軽減する必要があります。
「再読込」（Shift+F5など）も、やばいかも。。。

[ メッセージ編集済み 編集者: Jitta 編集日時 2004-03-15 17:44 ]
ichiro
会議室デビュー日: 2004/03/15
投稿数: 12
投稿日時: 2004-03-16 16:23
ありがとうございました。
NAL-6295さんの
http://www.atmarkit.co.jp/fdotnet/aspnet/aspnet15/aspnet15_01.html
を読んで少しづつですがわかってきました。
皆さんありがとうございました。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2004-03-16 16:38
引用:

NAL-6295さんの書き込み (2004-03-15 14:47) より:
NAL-6295です。

ちなみに内部的には、セッションは要求毎（クライアント毎）に作成されるスレッドの事です。
要求(Request)と返答(Response)は勿論クライアント毎に異なるべきなので、スレッド毎に用意されています。

つまり、各セッション専用なわけですので、上記例のような、A1ユーザとA2ユーザがテレコになるような事はおきません。
--
ちなみに、マルチプロセスではなく、マルチスレッドです。

ちょっと語弊がありそうな表現なんですが…

ichiroさんの「ASP.NETはセッション間が干渉しあわないような仕組みになっていますので」 ってどこに書かれてたことなんですかね？
セッションという言葉が具体的にどういうものをさすかは文脈で変わりそうなので…

ASP.NETのセッションというと、普通には所謂セッション管理の機能辺りをさすと思われますが、そういう意味だと、「セッションは要求毎（クライアント毎）に作成されるスレッドの事です。」はちょっと勘違いしてしまいそうです。

元々の、リクエストの変数（微妙な表現）が混ざってしまわないのは、セッションとは無関係ですよね。また、スレッドとも直接は関係ありません。
まあ、この辺は詳しい記事や書籍なんかちゃんとを読めば、なんとなく大丈夫かなとは思いますが。

[ メッセージ編集済み 編集者: なちゃ 編集日時 2004-03-16 16:50 ]
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2004-03-16 16:51
NAL-6295です。

端折って記述したため、誤解を招く表現になってしまったみたいですね。

基本的には、ASP.NETのセッション管理まわりの事を述べたのですが、
それぞれのクライアント要求は、それぞれ独立して処理されるわけで、
単位的には似たようなモノとしてセッションという言葉を便利に使っ
てしまっていました。

申し訳ないです。





[ メッセージ編集済み 編集者: NAL-6295 編集日時 2004-03-16 16:56 ]
顔爺
ベテラン
会議室デビュー日: 2003/10/03
投稿数: 52
投稿日時: 2004-03-16 17:03
簡単に実装できる DB の排他制御としては、Optimistic Offline Lock というものもあります。

実装としては以下の通りです。

1.テーブルに「バージョン番号」フィールドを設けます。

2.セッションが行データを読み込む(SELECT)する時、バージョン番号も取得します。

3.テーブルの更新(UPDATE)を行う際には、WHERE 句に行データのバージョン番号が
　セッションが保持しているバージョン番号と等しいことという条件を付加し、
　SET で行データのバージョン番号を +1 します。

4.上記 3. の更新件数が 0 件なら、既に他のセッションで更新処理が行われています。


以下、例

1. A1がAを表示(VER =100)
SELECT DATA1,DATA2,...,VER FROM xxx WHERE ID=yyy;
2. A2がAを表示(VER =100)
SELECT DATA1,DATA2,...,VER FROM xxx WHERE ID=yyy;
3. A2が確定処理(WHERE VER =100 は成立するので UPDATE 成功、同時に VER を 101 に更新)
UPDATE xxx SET VER=101,... WHERE ID=yyy AND VER = 100;
4. A1が確定処理(WHERE VER =100 は成立しないので UPDATE 対象は 0 -> 失敗)
UPDATE xxx SET VER=101,... WHERE ID=yyy AND VER = 100;

«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）