- PR -

window.openだと処理を並列に行えない

投稿者投稿内容
さり
常連さん
会議室デビュー日: 2003/05/13
投稿数: 38
投稿日時: 2003-12-19 20:44
>べるさん
>なにやら不思議(私がそう思うだけだとおもいますが)な現象ですね。
私もどんどんはまってきてます。

引用:

新しく開いたページの初期処理で、Response.Cookies["ASP.NET_SessionId"].Value
を直接編集してしまえばOKでした。



と申し上げたのですが嘘でした。
上記の事を行うと、開き元も開き先も同じセッションIDに編集されました。
また、その後、セッションIDのフォーマットが不正だからか、
開き元・開き先両方に、同じ新しいセッションIDが付番されました。

window.openで開いたページはウィンドウ毎に別のセッションクッキーを持つのではなく、
同じセッションクッキーを持つ、という理解でよいのでしょうか?

となると、私の要望である、window.openで開いた時に開き元と開き先で
並列に処理を行いたい、というのは無理、という事なのでしょうか?
べる
ぬし
会議室デビュー日: 2003/09/20
投稿数: 1093
投稿日時: 2003-12-21 01:27
いや、
引用:
window.open('http://(IPアドレス)/WebApplication1/WebForm1.aspx')

window.open('http://(マシン名)/WebApplication1/WebForm1.aspx')
のようにして開くと並列処理されました。


ということです。あとはこれをグローバル環境ででもやってみてください。

(セッションIDの発行のされ方や、並列処理されない原因がそこにあるのかは
詳しく検証していません)
さり
常連さん
会議室デビュー日: 2003/05/13
投稿数: 38
投稿日時: 2003-12-22 11:05
>べるさん
ちょっとべるさんが先に出されたやつと合わせてやってみたのですが、
以下のように結果になりました。


WEBサーバもクライアントも同一の場合

<1>window.open('WebForm2.aspx')
並列処理不可

<2>window.open('http://(IPアドレス)/WebApplication1/WebForm2.aspx')
並列処理可能

<3>window.open('http://(マシン名)/WebApplication1/WebForm2.aspx')
並列処理可能

<4>window.open('http://localhost/WebApplication1/WebForm2.aspx')
並列処理不可


同一セグメントのLAN環境で、WEBサーバとクライアントは別
<5>window.open('WebForm2.aspx')
並列処理不可

<6>window.open('http://(IPアドレス)/WebApplication1/WebForm2.aspx')
並列処理不可

<7>window.open('http://(マシン名)/WebApplication1/WebForm2.aspx')
並列処理不可

となり、ただ、WebForm1をマシン名指定で、WebForm2をIPアドレス指定で行うと、
(もしくはその逆)並列処理は可能になっています。
正直、原因は・・・・・私のスキルでは完全に白旗です><




自分が検証用にしているファイルをネットに上げますので、
もし、よかったらお試し頂けたら幸いにございます。
http://www.geocities.co.jp/Outdoors-River/4038/heiretsu.lzh
VS.NET2003用になっています。VS.NET2002の場合は、WebForm1とWebForm2をご使用下さい。

<環境>
1.仮想ディレクトリ名はWebApplication26です。

2.WebForm1.aspxの「WindowOpen(フルURL指定)」になっているボタンのonclick処理の
SERVER_NAMEを、WEBサーバ名もしくはIPアドレスに書き直してください。

3.Class1にログを吐き出す関数を書いています。
その関数を使用される際は、吐き出し先のフルパス名を書き換えてください。
今は使用していません。

<使い方>
1.WEBサーバ・クライアント共に同一PCだとします。
2.WebForm1.aspxを開いてください。
3.WindowOpenボタンを押すと、WebForm2.aspxページが別ウィンドウで立ち上がります。
4.どちらの画面も、スリープ処理ボタンを押すと5秒サーバ側でスリープし、
  処理の終了時刻をテキストボックスに書き込みます。
5.まず、WebForm1ページのスリープ処理ボタンを、続いてWebForm2ページのスリープ
  処理ボタンを押してください。
6.WebForm2の処理は、WebForm1の処理の5秒後に終了している事が分かります。

7.現在開いているWebForm2ページを×ボタンで閉じます。
8.WebForm1ページの「WindowOpen(フルURL指定)」ボタンを押すと、
  WebForm2ページが開きます。
9.同じように、両方のスリープ処理ボタンを続けて押してください。
10.処理の時間を確認して下さい、先ほどより全く少ない時間で動作しています。



*Page_Loadの動作する時刻をログに吐き出したり、セッションを切ったりする等の
これまでの検証もできると思います。ログを吐き出す場合は、Class1をご使用下さい。
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2003-12-22 11:20
ども、ほむらです。
-------
引用:

「POST /webapplication1/webform1.aspx」はリクエストで、
「200」はレスポンスだと理解しています。
レスポンスが出ているので、この「20:18:25」時間部分は、レスポンスを
返す時間に書き込んでいるという理解は間違っていますでしょうか?


レスポンスには違いはないのですけどこの場合リクエストに対するレスポンスですね。
200は成功を意味します。
ためしに、存在しないページを指定してあげると
404(NotFound)という形になると思うのですが。
ステータスコードについては以下のサイトを参考にしてください。
http://www.studyinghttp.net/

僕自身もこのあたりは曖昧なのですが
レスポンス(エンティティの出力)に何秒かかったという情報はログには残らない気がします。

引用:

「Bを開いた後にAにリダイレクト」のあたりがちょっと分かりません。
「Bを開く」事はサーバサイドではなく、クライアントサイドで行っています。


やっぱり僕勘違いしてましたね。一度クライアント側へ表示した後の話だったのですね。
原因とか解決方法とかわかりませんけど、、、

並行処理する場合としない場合での違いとしてはプロセスがありますね。
単独で立ち上げた場合は、別々のプロセスですけど、
新しいウィンドウ開いた場合には同一のプロセスになります。
もしかしたらこの辺も関係しているのかもしれませんね。
セッションはプロセスに依存している可能性もありますし。。。

.NETのことは知らないのでこれ以上突っ込んだ話できないのですけど
Thread.Sleep(5000);
の部分をもっと限定とかできないのでしょうか?
最悪、ページAの処理とページBのスレッドが同一である可能性の否定できないかも。
# とういうか、そもそも同じプロセスで走っている時点で同期化された同じ関数にとんでる?
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2003-12-22 11:55
引用:

べるさんの書き込み (2003-12-19 19:39) より:
なにやら不思議(私がそう思うだけだとおもいますが)な現象ですね。
(以下略)


 順番に考えると、まっとうなように思います。

1.複数の要求からは、並列に処理されなければならない
2.単一(同一)の要求に対しては、直列に処理しなければならない

 例えば、window.openで、おそらく「別のウインドウが表示される」ことを想定していらっしゃると思いますが、よく考えると「別のフレームに表示する」のも、これなんですよね。hrefのtargetでやる?それも確かですが、targetで指定するのはwindowの名前で、「別のアプリケーション」ではない、ですよね。同じように、window.openの第2引数も、windowの名前です。

 「フレームで」という前提の元で考えると、「検索指定」フレームで「検索開始」を指定して、「検索結果」フレームに表示される前にもう一度「検索開始」をすると、それは「検索結果」フレームが表示された後に処理されるのではないでしょうか。
 または、「情報」ウインドウと「詳細」ウインドウに別れていたとして、「詳細」で指定した内容が「情報」に反映されるとします。「情報」ウインドウで「登録」を指定すると、それは「詳細」で指定した内容が「情報」に反映された後に動作して欲しいのではないでしょうか。

 「UI」の部分と「ロジック」の部分が別個のところにあるため、「処理の流れ」も別個のものとして考えているので混乱するので、「Windowsアプリだとどうなるか」ということを考え、その後で「UI」と「ロジック」を分ければ、整理されませんか?


ということだと思うのですが、如何でしょう???(かなり弱気)
さり
常連さん
会議室デビュー日: 2003/05/13
投稿数: 38
投稿日時: 2003-12-22 12:03
> 僕自身もこのあたりは曖昧なのですがレスポンス(エンティティの出力)に
> 何秒かかったという情報はログには残らない気がします。
1.こういうリクエストが来ました。
2.こういうリクエストに対してこのようなレスポンスを返しました。

2のログだけが記録されて1のログは残らないわけですね。
その時にはちょっと1の部分を期待していたのですが。


> やっぱり僕勘違いしてましたね。
いえいえ、私の書き方がまずかったためです、すみません。


> 最悪、ページAの処理とページBのスレッドが同一である可能性の否定できないかも。
スレッドが同一になる場合とならない場合の法則が良く分からないのです。

セッションを切れば並列になるという現象から、同一のセッションIDからは同一のスレッド
をサーバサイドでは使用する→よって並列に処理は行う事はできない。
という形なのかと想像していたのですが、

べるさんの御指摘でURLの指定の仕方によっても並列処理可能・不可能という現象が、
上記では説明できなくて・・・・
べる
ぬし
会議室デビュー日: 2003/09/20
投稿数: 1093
投稿日時: 2003-12-22 13:05
実験結果の情報提供しかできなく申し訳ないのですが、

Global.aspxを両方消したら並列処理されました。(片方づつは実験してません)
あと、おなじlocalhostアクセスでも別プロジェクトだと並列処理されました。
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2003-12-22 15:34
ども、ほむらです。
適当な発言のまま、暴走中です^^;;;;
------
引用:

1.こういうリクエストが来ました。
2.こういうリクエストに対してこのようなレスポンスを返しました。

2のログだけが記録されて1のログは残らないわけですね。
その時にはちょっと1の部分を期待していたのですが。


そうですね。
でもまぁ、HTTPヘッダを出力する時点で自分でログを書き出してあげれば最終的に
このログとの差分で何秒かかったというのが算出できるとは思うんですけど、
.NETの場合どこで書けばHTTPヘッダを直接処理できるんでしょうねー。
#まぁsleep()かける直前でも問題ないかもしれませんが。。。
#(sleepまでは一瞬でいくと思いますし)

引用:

> 最悪、ページAの処理とページBのスレッドが同一である可能性の否定できないかも。
スレッドが同一になる場合とならない場合の法則が良く分からないのです。

セッションを切れば並列になるという現象から、同一のセッションIDからは同一のスレッド
をサーバサイドでは使用する→よって並列に処理は行う事はできない。
という形なのかと想像していたのですが、

べるさんの御指摘でURLの指定の仕方によっても並列処理可能・不可能という現象が、
上記では説明できなくて・・・・


Web.configにこんな記述がありますけど。。。
コード:
    <!--  セッション状態の設定
          既定では、ASP.NET は Cookie を使用して、要求がどのセッションに属するかを識別します。
           Cookie が使用できない場合は、URL にセッション識別子を入力することで、セッションを見つけることができます。
          Cookie を有効にするには、sessionState を cookieless="false" に設定してください。
    -->
    <sessionState 
            mode="InProc"
            stateConnectionString="tcpip=127.0.0.1:42424"
            sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
            cookieless="false" 
            timeout="20" 
    />


ということは、クッキーと同じ制限が存在しそうなので、
/webapplication1/webform1.aspx ならば、
webapplication1/ にあるページは同一のセッションIDを持つことになりそうですね。。。

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