パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

小田急予約サイトで競合状態バグによるトラブル」記事へのコメント

  • request/session/applicationの正しい認識が重要かと。(j2eeの場合)
    あとはstaticの認識と。
    • staticの認識を言うならば、synchronizedとvolatile、sleep()・wait()・notify()・notifyAll()の正しい認識も同時に必要でしょう。
      staticを使ってのパフォーマンス向上は諸刃の剣のはずなのだけど…やたらとpubli staticなsetter/getterを作りたがるPGがたまに居て…_no
      • 突っ込みどころは色々あるが、static な getter/setter は bean ならあり得ないんじゃ…。
        staticメソッドから非staticな変数へはアクセス出来ないし。
        • いや、まじめに

          public class Configuration {
              private static String s1;

              public static void setS1(String s){
                  s1 = s;
              }

              public static String getS1(){
                  return s1;
              }
          }

          こんなの書いてきた人います。しかも複数…。
          親コメント
          • by Anonymous Coward on 2005年10月14日 16時21分 (#814085)
            超有名商用DB作っている会社が出しているJavaの開発環境の
            Struts使ったフレームワークのActionFormでこれやられました。
            バグを指摘したら各Actionでresetメソッド呼んでくれと回答されて
            マジ切れしました。

            DB以外に手出すなよこの会社~!!!!
            そのDBもバグで酷い目にあった事もあるけど・・・

            会社名は言わなくても解るよね。
            親コメント
          • ぱっと、思い付いたので。

            『newしないとクラスが使えないようだが?』
            『staticなんて飾りです。偉い人にはそれが分からんのです』

            まあ、Math classみたいにそれ自体にデータを持たない場合の
            static methodはありだし、システム全体の排他制御のための
            オブジェクトなど複数オブジェクトがあると困るような場合は
            Singletonが正しいアプローチだけどさ。
            なんにしろ、設計に存在しないグローバル変数はバグの元。
            親コメント
            • > なんにしろ、設計に存在しないグローバル変数はバグの元。

              そういうグローバル変数に触れていないメソッドであることを、
              コンパイラにも分かる形で宣言できたらいいのに、と思ったことがあります。

              例えば、java.lang.Integer の parseInt(String) なんかは、入力された引数のみ が
              戻り値に影響を与えるべきメソッドですが、本当に大丈夫か、と疑い出したら、
              ソースを追ってみるしかないです。
              • スレッドセーフであるかはJavaDocで表明します [sun.com]。

                >別なスレッドの影響を受けちゃうような実装に*なっていない*ことを、
                >表明できる仕組みがあればいいのになぁ
                コンパイラに対してってのは難しいですねぇ。
                コンパイラに宣言する以上はコンパイラは実装をチェックする
                必要がありますが、そのメソッドから呼び出される処理は全部
                再帰的にチェックしなくてはいけません。
                流石にコンパイラの手に負えないですね。クラスファイルの
                形式にも変更が必要になります。
                変に採用すると
                「ちゃんとスレッドセーフだけど、コンパイラが文句を言うので表明できない」
                なんてケースが出てきそうです。

                >そういうグローバル変数に触れていないメソッドであることを、
                >コンパイラにも分かる形で宣言できたらいいのに
                グローバル変数云々だけならコンパイラにもできそうですが、
                スレッドセーフかどうかはとは別問題なので、役立つ場面は
                少なくなります。

                ありがちなパターンを見つけ出したいなら、FindBugsなどの
                ツールを使って「バグっぽい」コードを警告してもらうのが
                限界でしょう。
                それ以上のことは、JavaDocの表明を信じる or 自分でソースを追いかける しかないです。
                親コメント
              • 今ならスレッドセーフかどうかを宣言するにはアノテーションを使えばええんではないですか。
                親コメント
              • あ、クラスファイルに印を付けるだけならアノテーションでもいけますね。
                ただ、アノテーションは「スレッドセーフをコンパイラに対して表明する」ではなく、「ツールや
                他の開発者にそう主張している」ですから、JavaDocでの表明と本質的な違いがないです。

                ・他の開発者に伝えるのなら、JavaDocで表明する
                 (フォーマットを統一したりしたいなら-tagオプションやTaglet、Doclet)
                ・コンパイラやツールがスレッドセーフの保障をするのは無理
                ・作成者の表明(JavaDocやアノテーション)を疑うならソースを追うしかない
                が本題です。
                親コメント

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

処理中...