2

状況

次のことを想像してください。

次のような列挙があります。

enum State{
  INITIAL{
    @Override
    public void proceed(){...}
  },
  NEXT_STATE{
    @Override
    public void proceed(){ ... }
  },
  //and so on
  TERMINATED;

  public void proceed(){}
}

次に @Entity です。このエンティティは、注文を処理するアプリケーションのユースケースを表します。と呼びましょうActivationUseCase。ActivationUseCase（私のUseCase基本クラスから継承する他のクラスと同様に）状態と呼ばれる属性があり、State.

putzzle の最後の部分は、EJB 3.1 Bean です。この Bean は、 を取得し、それに対してproced ActivationUseCase() を呼び出します。

アイデアは、@Entity可能な状態 (列挙型) に関するすべての情報を に保持させ、各状態が必要なときに何をすべきかを知ること.proceed()です。

問題

proceed() メソッド内には、静的コンテキストがあります。しかし、他の EJB を呼び出したい場合もあります。そのため、誰かが JNDI ルックアップ (ローカル) を開始し、必要な Bean を呼び出します。私見はかなり醜く危険ですが、それはここでの問題ではありません.

明確にするために、疑似呼び出しのスタックを次に示します。

    MyServiceBean.myServiceMethod()
    |- ActivationUseCase.proceed()
       |- ManuallyLookedUpEJB.anotherServiceMethod()

したがって、トランザクションを開始し、インスタンスをMyServiceBean.myServiceMethod()取得して呼び出します。次に、 (new InitialContext()...)を検索して を呼び出します。ActivationUseCaseproceed()ManuallyLookedUpEJBanotherServiceMethod()

質問

トランザクションはどうなりますか? それはどこから始まりますか？それはカバーしanotherServiceMethod()ますか？どうすればこれをデバッグできますか?

免責事項

enum-contains-logic コンストラクトについては (今は) 説明したくありません。実際、全体をリファクタリング (書き換え) する理由を集めています。この構成は良い考えではないという私の主張を裏付けるいくつかの理由が必要です。

4

1 に答える 1

1

トランザクションは、他のメソッド呼び出しと同様に伝播します。したがって、ManuallyLookedUpEJB.anotherServiceMethod()REQUIRES_NEW トランザクションの伝播がない限り、 によって開始されたトランザクションと同じトランザクションで実行されMyServiceBean.myServiceMethod()ます。

于 2013-04-08T13:37:44.937 に答える