- ベストアンサー
Strutsでスレッドセーフに実装する方法
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
"基本的には"スレッドセーフです。 別のスレッドから、同じActionクラスインスタンスを参照するということはありません。 Actionクラスのインスタンスは使い回されるという特性を理解していれば、synchonizedを使わなくともスレッドセーフな処理に出来るということです。
その他の回答 (1)
Struts の Action クラスは、基本的にはスレッドセーフです。
関連するQ&A
- スレッドセーフなクラスのサブクラスは？ synchronizedって継承先では？
1)メソッドにsynchronizedキーワードをつけた時、継承先のサブクラス側でもsynchronizedは生きているのでしょうか？ 2)もし生きていると サブクラス側で、synchronizedをとりけしたい場合 synchronizedをつけない形でオーバーライドして 中身の実装は super.メソッド名(); だけにするという方法しかないということでしょうか？ 3)なお、 サブクラス側で、synchronizedキーワードを追加しながら メソッドのオーバーライドができるということは 知っています。 4) (1)の答えが生きていない。とすれば・・。 スレッドセーフなクラスをがんばって作成しても、 サブクラス作成者がいちいち意識しなければ、 サブクラスはスレッドアンセーフになってしまう ということでしょうか？ サブクラス作成者がたとえ、赤の他人でまったく、 コミュニケーションをとれない状況であろうとも、 そうならないようにするためのしかけを 作るためのテクニックはあるでしょうか？ なお、これはクラスをfinalしたくない場合の話です 以上です。
- ベストアンサー
- Java
- Struts2のスレッドセーフについて
Struts2はスレッドセーフでリクエストごとにアクションクラスのインスタンスができると聞いています。 リクエストごとにインスタンスができるということはアクションクラス内で使うオブジェクトは スレッドセーフでないHashMapのようなオブジェクトを使っても大丈夫ということでしょうか。
- ベストアンサー
- Java
- サーブレット、Strutsのスレッドの動きについて
ここ教えてgooでもこの類の質問は多いですが、現在ある問題に直面しています。過去の質問を見てもピンと来るものがなかったので、２つ質問させてもらいます。 １． １リクエスト１インスタンスではないことは過去の質問やブログでもわかりました。ということは１リクエスト(サブミット)１スレッドという解釈でよろしいでいいと思います。これを踏まえて例えさせてください。 １０台の端末からほぼ同時に同一アクションへサブミットした場合、１つのインスタンスから１０スレッドが生まれるということでいいでしょうか？今直面している問題は、トークンチェック等２重サブミット対応をしていない状態で、１台の端末(自分)でサブミットを連打した場合(例えば１０回)、１０台の端末から同時アクセスした場合と同じ状況になるのでしょうか？ ２． 以下はソースのイメージです。 // アクションクラス BarAction継承クラス { execute { ～中略～ HogeLogic logic = new HogeLogic(); logic.doLogic(); ～中略～ } } // ロジック HogeLogicクラス { //インスタンス変数 FooService service=new FooService(); doLogic { ～中略～ service.insert(); ～中略～ } } 分かりづらかったら申し訳ないです。 言いたいことはBarAction#execute内でHogeLogicクラスを生成しています。ということは生成されたHogeLogicのインスタンス(logic)はスレッドセーフだと思います。 しかしHogeLogicクラスではFooService.serviceがインスタンス変数として宣言されています。 この場合、FooService.serviceはスレッドセーフなのでしょうか？
- ベストアンサー
- Java
- 継承・実装の関係で悩んでいます。
継承・実装の関係について悩んでいます。 ここでは、アクセス制御を考えずに、インスタンスかstaticかabstract(ここではabstract final staticやabstract classのこと)の違いで、どう継承するのか考えています。 // 継承 はメソッドのオーバーライドのことを考えます。(オーバーロードは考えない) クラスAからクラスBでオーバーライドしたメソッドは、 クラスCでさらにオーバーライドできるのでしょうか？ クラスCが クラスBのクラスAからオーバーライドしたメソッド をクラスBのメソッドとして見たときに、オーバーライドすることは可能なのでしょうか？ クラスA │ インスタンスフィールドA │ staticフィールドA │ │ クラスA() { } │ │ インスタンスメソッドA () { } │ staticメソッドB() { } ↓ クラスB extends クラスA │ インスタンスフィールドA // 継承 │ インスタンスフィールドB │ staticフィールドB │ │ サブクラス1() { } // コンストラクタは継承しない、super()で呼び出す │ │ インスタンスメソッドA () { } // 継承 │ │ インスタンスメソッドB () { } │ staticメソッドB () { } ↓ クラスC extends クラスB implements インタフェースD, ... ↑ インスタンスフィールドA // クラスBのフィールドを継承 │ インスタンスフィールドB // クラスBのフィールドを継承 │ インスタンスフィールドC │ staticフィールドC │ │ サブクラス2() { } │ │ インスタンスメソッドA () ｛ ｝ // クラスBのメソッドを継承 │ インスタンスメソッドB () { } // クラスBのメソッドを継承 │ インスタンスメソッドD () { } // インタフェースDのメソッドを実装 │ インスタンスメソッドE () { } // インタフェースDのメソッドを実装 │ │ │ インスタンスメソッドC () { } │ staticメソッドC() { } │ interface インタフェースD extends インタフェースE ↑ │ staticフィールドD // public static final │ │ インスタンスメソッドD() { } // public abstract │ インスタンスメソッドE() { } // 継承 │ interface インタフェースE staticフィールドE // public static final インスタンスメソッドE() { } // public abstract
- ベストアンサー
- Java
- StratsのActionクラスのexecuteメソッドは何故abstructじゃないの?
StratsのActionクラスのexecuteメソッドは何故abstructではないのでしょうか？ Actionクラスを実装するのであれば必ずexecuteを実装すると思います。 なので必ずexecuteメソッドをオーバーライドすると思います。 既に実装してあっても意味がないのではないかと感じました。
- ベストアンサー
- Java
- Thread.sleep()はすべてのスレッドを停止する？
Threadを継承したCarというインスタンスを５つ作ってstart()させたとします。 そのあと、クラスメソッドのThread.sleep(1000)をすると、すべてのThreadインスタンスが１秒止まるのかと思ったのですが、そうではないといわれました。 クラスメソッドのThread.sleep()は何をsleepさせるのでしょうか？
- ベストアンサー
- Java
- C++で参照カウンタを実装したいのですが
こんにちは。 C++でクラスに参照カウンタを実装したいのですが、もしも実装する場合、 class CRefCounter { 参照カウンタとAddRef、Releaseメソッドを仮想メソッドとして実装 }; このクラスを継承して直接使う方法と、 class IRefCounter { 参照カウンタとAddRef、Releaseメソッドを純粋仮想メソッドとして宣言 } このクラスを継承して継承側で実装する方法とがあると思うのですが普通はどちらを使うものでしょうか？
- ベストアンサー
- C・C++・C#
- Strutsのバージョンアップによる変更点を教えて下さい。
Strutsのバージョンアップによる変更点を教えて下さい。 ■ Struts 1.0 → 1.1 の変更点・互換性 ・org.apache.struts.action.Action#perform が非推奨に →performメソッドの代わりに executeメソッドを使用します。 ・org.apache.struts.action.Actionクラスのクラス変数が非推奨に ■ Struts 1.1 → 1.2 の変更点・互換性 ・org.apache.struts.action.Action#perform が削除 ・GenericDataSource、GenericConnection が削除 ・ActionError、ActionErrors が非推奨に →代わりに ActionMessage、ActionMessagesクラス が推奨。 ・org.apache.struts.tiles.actions.NoOpAction が削除 →代わりに ForwardActionクラスを使用。 ここまでは、ネットにあったのでわかりました（正確性は不確か）。 これ以降のバーションアップでは、どのような変更があったのか、バーションアップごとに教えていただけると幸いです。 よろしくお願い致します。
- 締切済み
- Java
- サーブレット スレッドセーフについて
サーブレットのインスタンス変数、クラス変数はスレッドセーフではありませんが、 doGet などのほかに勝手に作ったメソッドは、スレッドで動作するのでスレッドセーフと考えていいでしょうか？
- ベストアンサー
- Java
- スレッドセーフなクラス一覧
スレッドセーフなクラス一覧が分かるWebサイトや、そのクラスがスレッドセーフかどうか知る方法を探しています。 複数スレッドで共有オブジェクトにアクセスする際に、synchronizedブロックをかけるのですが、そのオブジェクトがスレッドセーフかどうかすぐに分かる方法があると便利だなぁと思って探しています。 例えば、Stringはスレッドセーフ、SimpleDateFormatはアンスレッドセーフ等の情報が一覧で欲しいと思っています。 なるべく多くのクラスを網羅していればそれだけありがたいです。 ご存知の方がおられましたら教えてください。 よろしくお願いします。
- ベストアンサー
- Java
補足
了解しました。 基本的にはOKかと思いますが具体的に他に 何か気をつけた方が良い事はありますでしょうか。