EJB Transaction - 静态上下文 - 坏主意？

Question

情况

想象一下：

有一个这样的枚举：

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的属性，其中包含State。

最后一部分是一个EJB 3.1 bean，它检索ActivationUseCase并在其上调用proceed（）。

我们的想法是让@Entity保存关于它的所有信息的可能状态（枚举），并且每个州都知道在必须.proceed()时该怎么做。

问题

在proceed（）方法中，我们有一个静态上下文。但我们可能想调用其他EJB。所以有人开始做JNDI查找（本地）并调用我们需要的bean。 恕我直言，这是非常丑陋和危险的，但这不是问题。

为了清楚起见，这是一堆伪调用：

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

因此MyServiceBean.myServiceMethod()启动一个事务，检索ActivationUseCase实例以在其上调用proceed()。然后我们查找ManuallyLookedUpEJB（新的InitialContext（）...）并调用anotherServiceMethod()。

问题

交易会怎样？它从哪里开始？它会涵盖anotherServiceMethod()吗？我怎么能调试这个？

声明

我不想讨论enum-contains-logic结构（现在）。事实上，我正在收集重构（重写）整个事情的理由。我只是需要一些理由支持我的说法，即这个结构不是一个好主意。

Answer 1

事务将像任何其他方法调用一样传播。因此，除非ManuallyLookedUpEJB.anotherServiceMethod()具有REQUIRES_NEW事务传播，否则它将在与MyServiceBean.myServiceMethod()启动的事务相同的事务中执行。