アカウント名:
パスワード:
# 昔それで情報流出するバグを見たことがあるID
ぱっと思いついたありがちな理由は、 Servletで何も考えずにフィールドを作っちゃった [atmarkit.co.jp] 。他にもいろいろありそうですが。
この例では、マルチスレッドモデルでServletを動作させていたため、スレッド間でインスタンス変数paramが共有され問題となったのである。つまり、複数の端末から同時にServletへアクセスすると、paramの値がスレッドごとに書き換えられてしまい、タイミングによっては、 getParameters()メソッドを実行したときのparamの値と、その後に呼ばれるexecute()メソッドやdisplayPage()メソッドでのparamの値が異なる場合があるのである。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
え…？ (スコア:1)
Re:え…？ (スコア:1)
# 昔それで情報流出するバグを見たことがあるID
Re:え…？ (スコア:1)
具体的にはどのようなバグだったのでしょう？
May the source be with you... always.
Re:え…？ (スコア:2, おもしろおかしい)
ぱっと思いついたありがちな理由は、 Servletで何も考えずにフィールドを作っちゃった [atmarkit.co.jp] 。他にもいろいろありそうですが。
Re:え…？ (スコア:2, 参考になる)
Servletと「アプリ」とを等価だと思ったら嵌まりますよね。
Servletは結局、状態を持たないようにコーディングするのがお洒落つーかマトモ。
状態は、Sessionにぶら下げるカタチで別途用意したオブジェクトに、持たせるべき。
デスクトップ(^^;アプリはメモリ上に実行コードと状態とが一対一で存在する
(厳密には違うのかも知れないが、OSがメモリマップによってそれを隠蔽する)
わけだけど、Servlet方式だと1つのコードに対してProcess(==Session)じみた状態が複数つくことになる。
なので、所謂状態はServlet(==コード)に持たせてはいけない、という配分をするのが、自然なOOデザイン。
あと、同じような心配は、バック(?)のDBのほうのSessionについてもいえそうです。
ん。JDBC風にいえばConnectionかな。
少なくとも一人(1Session)につき排他的に1つのConnectionが
DB系の処理をしてる瞬間には割り当てられていないとならん。
あと、中間ファイルにも充分気をつけないとね。
てーか、出来るだけ中間ファイルを作らないのが吉。
Sessionとかのメモリ上のものは「無名」で作れるけど、
ファイルは(現代の普通のOSでは)「無名」に出来ないので、
排他制御のために名前の管理をもしないとならなくなる。
たるい。
＃forkやpopenを知らないばっかりに中間ファイルを作る、ってのは寒いので勉強して欲しいからG7
素人のしったかチャネラーうざい (スコア:0)
＞Servletは結局、状態を持たないようにコーディングするのがお洒落つーかマトモ。
＞状態は、Sessionにぶら下げるカタチで別途用意したオブジェクトに、持たせるべき。
ServletのSessionオブジェクトは、単なる変数のテーブル。
(更新をトリガにEvent発生とかできるけどね。)
対して、M$とかのAPIでは、Session==アプリみたいな、素人に判り易い構造になってたと記憶。
Sun/Javaの "Simple is Best" の信念には、時々はっとさせられる事が多いのだけど。JavaのSession管理のデザインは、シンプル化し過ぎて
Re:素人のしったかチャネラーうざい (スコア:1)
Javaだとそれが限界でしょうね。
動的性を捨ててる言語だから。
そういう意味ではBSFにでも期待したほうがいいのかも。
つまり動的な言語に仕事を依頼するってカタチね。
そういやCocoonとやらのフロー記述言語はJavaScriptベースだそうですね。
JavaScといえばHashtableとObjectが一体化したような言語仕様なわけで、
原理的(^^;には正にお悩みの問題を直接解決しちゃう言語。
まあ、それ以前に、Java言語自体がウザイというご意見ならば、賛同。
俺の元意見も、Java選ばざるを得ないならばという限定つきっす。
>＞Servlet方式だと1つのコードに対してProcess(==Session)じみた状態が複数つくことになる
>Processじゃなく、Threadだよん（藁
ん？あ。
「じみた」までで一括りのつもりです。
「Processじみた状態」ね。
＃たしかに日本語の組み合わせが変だったな。
あと、ProcessとThreadの違いについて噛み付かれる(^^;のでしたら、
「Lightweight Process」という言葉もご存知ですよね？
ProcessとThreadは、似てる面もあれば違う面もあるわけです。
デスクトップ/スタンドアロンなプログラムとの対比という文脈では
「スタンドアロンのProcess」と「鯖のSessionとThread」という対比で書くのが
向いてると思ったんで、わざとThreadと書いても良さそうな個所にProcessという単語を使ったんだけど…
（＾＾；ウザイ (スコア:0)
幕張でNET&COMやってるから、行って来い。
＞Javaだとそれが限界でしょうね。
＞動的性を捨ててる言語だから。
(後略)
脈絡ない発言は慎むようにｗ
だからキミは、愚かだと言われるんだｗ
＞あと、ProcessとThreadの違いについて噛み付かれる(^^;のでしたら、
＞「Lightweight Process」という言葉もご存知です
今時プロトタイプベース・オブジェクト指向で喜んでる (スコア:0)
プロトタイプベース・オブジェクト指向
http://pc2.2ch.net/test/read.cgi/tech/1070886635/
Re:（＾＾；ウザイ (スコア:1)
まあ、うざいと言ってる割には随分親切なコメントなんで、なんかよく判らぬが。
>引篭り
>幕張
残念ながら近年は篭ってないんだ。
よって幕張云々も(なんか知らぬが、なんか有るならば)行けない。
＃幕張の某巨大企業には二度と行きたくないのでG7
てか、多くの職業者って、会社に篭ってるんだよな。
>＞Javaだとそれが限界でしょうね。
>脈絡ない発言は慎むようにｗ
ないか？
>このネタでは「データ共有プロセス」である事を指摘しないと、
>的外れなんだよ
ん？それって当たり前じゃん。
だから「指摘」するまでもないと思うのだが。
＃ていうか「一対多」とかいう言い回しが「共有」と結局同じ事を言ってることになると思うが。
あれれ？ (スコア:0)
＞まあ、うざいと言ってる割には随分親切なコメントなんで、なんかよく判らぬが。
典型的な思い過ごしでしょう。
> >引篭り
> >幕張
(略)
微笑ましい程必死でいらっしゃるｗ
幕張某社に随分怨念を持ってらっしゃるｗ
＞＃ていうか「一対多」とかいう言い回しが「共有」と結局同じ事を言ってることになると思うが。
Ｇ７氏の全発言をヲッチしないと、レスつけちゃいけないのかぁｗ
それは大変ｗ
プロセス云々を指摘された段階で、それを言うべきでしょうね。