問題タブ [ejb-3.0]

次の EJB 3 インターフェイス/クラスがあるとします。

そして、Bean にアクセスする別のFooRepositoryBean :

ただし、FooRepositoryBean の delete メソッドが呼び出されたときにオーバーライド メソッドが実行されることはありません。代わりに、で定義されている削除メソッドの実装のみAbstractRepositoryが実行されます。

私は何を間違っていますか、それともジェネリックと継承がまだうまく連携していないというのは、単に Java/EJB 3 の制限ですか?

私のチームは、Web フロントエンドを備えた新しいサービス指向の製品を開発しています。どのテクノロジーを使用するかについての議論では、JBoss アプリケーション サーバー、Flex フロントエンド (Adobe AIR を使用したデスクトップ展開も可能)、およびクライアントとサーバーをインターフェースする Web サービスを実行することに決めました。

ビジネス ロジックにどのサーバー テクノロジを使用するかについては、行き詰まりに陥っています。大きな議論は EJB3 と Spring の間であり、最大の関心事はスケーラビリティとパフォーマンス、そしてコード ベースの保守性です。

ここに私の質問があります：

1. EJB3 対 Spring の賛成または反対の議論は何ですか?
   • それぞれにどのような落とし穴がありますか?
   • 良いベンチマーク情報はどこにありますか?

JPA エンティティを Oracle 10g と組み合わせて使用​​すると、次のような非常に厄介な動作が発生します。

次のエンティティがあるとします。

このエンティティは Oracle 10g にマップされるため、DB にはT_ORDER主キーNUMBER列IDとTIMESTAMP列を持つテーブルが存在しますactivationDate。

このクラスのインスタンスを有効化日で作成するとします15. Sep 2008 00:00AM。私のローカル タイムゾーンは CEST ですGMT+02:00。このオブジェクトを永続化し、T_ORDERsqlplus を使用してテーブルからデータを選択すると、テーブルに実際に格納されていることがわかります。14. Sep 2008 22:00これは、Oracle db のタイムゾーンが GMT であるため、これまでのところ問題ありません。

しかし、今は厄介な部分です。このエンティティを Java プログラムに読み戻すと、オラクルのタイム ゾーンが無視されていることがわかり14. Sep 2008 22:00 CEST、これは明らかに間違っています。

したがって、基本的に、DB に書き込むときはタイムゾーン情報が使用され、読み取るときは無視されます。

これに対する解決策はありますか？私が推測する最も簡単な解決策は、Oracle dbs のタイムゾーンを に設定することですがGMT+02、残念ながら、同じサーバーを使用している他のアプリケーションがあるため、これを行うことはできません。

以下の技術を使用しています

MyEclipse 6.5 JPA と Hibernate 3.2 Oracle 10g シン JDBC ドライバー

シナリオ

• EJB バージョン 3 を使用して Web アプリケーションを開発しました。
• システムが展開され、配信され、顧客によって使用されます。

システムをゼロから書き直す必要がある場合、EJB を再び使用しますか?

いいえ: この質問には回答せず、代わりにこちらに回答してください。

はい: あなたの個人的な経験に基づいて、EJB が解決した重要で実際の問題を 1 つ挙げてください。

答えに問題が1 つだけ含まれるようにします。これにより、他の読者が EJB の最高の機能に投票できるようになります。

次のようなステートレス Bean があります。

通常、クライアントは processObjects(...) を呼び出しますが、これは実際にはエンティティ マネージャーと対話しません。必要なことを実行し、処理するオブジェクトごとに個別に process(...) を呼び出します。process(...) の期間は比較的短いですが、processObjects(...) はすべてを実行するのに非常に長い時間がかかる可能性があります。したがって、オープントランザクションを維持したくありません。独自のトランザクション内で動作するには、個々のプロセス (...) 操作が必要です。これは、呼び出しごとに新しいトランザクションである必要があります。最後に、クライアントが process(...) を直接呼び出すためのオプションを開いたままにしておきたいと思います。

私はさまざまな種類のトランザクションを試しました: 決して、サポートされていない、サポートされている (processObjects 上で)、必須、新しい (プロセス上で) が必要ですが、merge() が呼び出されるたびに TransactionRequiredException が発生します。

メソッドを2つの異なるBeanに分割することで、機能させることができました。

しかし、これを1つのクラスで達成できるかどうかはまだ興味があります. トランザクション マネージャーは、個々のメソッドにより具体的な注釈が与えられている場合でも、Bean レベルでのみ動作するように見えます。したがって、トランザクションが同じインスタンス内で他のメソッドの呼び出しを開始しないように 1 つのメソッドをマークすると、どのようにマークされていても、トランザクションは作成されませんか?

JBoss Application Server 4.2.1.GA を使用していますが、具体的ではない回答を歓迎/優先します。

シナリオ

• EJB バージョン 3 を使用して Web アプリケーションを開発しました。
• システムが展開され、配信され、顧客によって使用されます。

システムをゼロから書き直す必要がある場合、EJB を再び使用しますか?

はい: この質問には回答せず、代わりにこちらに回答してください。

いいえ: 個人的な経験に基づいて、EJB を使用しない最大の理由を入力してください。

答えには理由が1 つだけ含まれるようにします。これにより、他の読者が EJB 3 を避ける最大の理由に投票できるようになります。

リモート EJB を呼び出すときに、さまざまなドライバー情報を指定する必要があるのはなぜですか?

URL/ポートを指定するだけでよく、EJB コンテナーは他のすべてのものを解決する必要があるのではないでしょうか?

私はちょうど始まろうとしているプロジェクトに取り組んでいます。別のプロジェクトで忙しかったので、同僚が先に進み、新しいプロジェクトの仕様に取り組み始めました。私が入ったとき、彼らは単純な SQL で永続化を行うことを選択したばかりでしたが (ただし、Hibernate を追加するという私の提案をすぐに受け入れました)、私が聞いたことのないSymmetric DSというツールを使用してデータ複製を実行する必要があると主張しました。

私が知る限り、JBoss サーバー (現在の計画では Tomcat のみを使用する予定です) で EJB3 を使用すると、すべてのトランザクション/レプリケーションの問題が処理され、多くの頭痛の種から解放されるのではないかと心配しています。

皆さんは、このSymmetric DSをどのように見ていますか? (私はそれに対して何も反対していないことに注意してください.JBossが長い間存在し、非常に立派な評判を持っていることを知っているだけです)

2 つのソリューションをどのように比較しますか?

ありがとう！

EDIT : ところで、SymmetricDS は重複した主キーをどのように処理しますか? つまり、データベース A に行を追加し、データベース B に別の行を追加すると、両方ともおそらく同じ主キーで追加されますよね? 競合を避けるために、SymmetricDS はそれをどのように処理しますか? このフォーラムでの議論は、最初はその一部に対処しているように見えましたが、私の質問にはまったく答えていません。

私はEJB3（アプリとWebサービスレイヤーの場合はHibernate + Glassfish、WebUIの場合はLifton Glassfish）を使用してJavaで多層金融処理アプリケーションを開発中です。私のビジネスロジックを置きます。

このプロジェクトが開始されたとき、私たちの最初の概念は、ビジネスロジックの大部分をステートレスセッションBeanに入れることでした。ただし、時間が経つにつれて、EJBフレームワークによって提供される依存性注入が制限されすぎることがわかりました。そのため、ビジネスロジックの多くは、ステートレスセッションBeanの@PostConstructメソッドでGuiceによってアセンブルされるPOJOになりました。 。この進歩により、セッションBeanとPOJOの間のビジネスロジックが断片化されました。私は、これを修正するためのアプローチを見つけようとしています。

最初に、Web層でセッションBeanのリモートインターフェイスを使用して、UIとWebサービスレイヤーの両方からアクセスできるいくつかの機能を実行しようとしました。これは、@WebService注釈付きのステートレスセッションBeanによって提供されます。これは、永続性とパフォーマンスの観点からは悪夢であることが判明しました。エンティティグラフが非常に大きくなる可能性があり、分離されたエンティティグラフを永続性コンテキストに再アタッチするとエラーが発生しやすいことが判明したため、ソリューションはオブジェクトの受け渡しを開始することでした。必要な場所でデータベースからエンティティを検索します。

私の基本的な質問はこれです：ビジネスロジックをセッションBeanとPOJOのどちらにするかを決定するために、どのような原則とガイドラインを提案できますか？複雑なオブジェクトグラフがある場合、エンティティBeanを渡すことが理にかなっているのはいつですか。

注釈付きの EJB3 クラスから ejb-jar.xml 構成ファイルを作成するツールを探しています。XDoclet のようなものですが、コメントのタグではなく注釈用です。