java - 典型的 EJB3/JPA/JSF 中的事务范围是什么？

Question

假设您有一个带有 EJB3/JPA 和 JSF 堆栈的 Web 应用程序。据我所知，您可以使用不同的托管 bean 设计您的屏幕，例如，让我们假设一个 HeaderBean 和一个 ListingBean。由于 EJB3 AFAIK 中没有 OSIF 模式，以下伪代码中执行了多少个不同的事务:

@ManagedBean
class HeaderBean {
  @PreConstruct
  load(){
    // enters transaction boundary, probably will create a new tx
    headerInfo = ejb.loadFromDb();
  }
}

@ManagedBean
class ListingBean{
  @PreConstruct()
  list(){
    // enters transaction boundary, probably will NOT join the headerBean tx
    List<Data> listing = eao.loadFromDb(0, 20);
  }
}

据我所知，当您离开 EJB 层时，所有事务都已提交；因此，如果我从表示层调用两个不同的 SLSB，它将在两个不同的事务中运行(并且可能打破我的 ACID 期望，对吧？)。

---

澄清:我知道 EJB3 事务行为，例如 required、never、requires_new 等。我的问题更多是关于 View-First(例如 JSF)如何促进这种屏幕数据可能跨越多个事务并因此可能不准确的设计。

与短交易但数据不正确相比，我更喜欢较长的交易但数据正确。我想知道 jBoss Seam 等新框架是否以某种方式促进了这一点或提供了替代设计(例如:Open-Session-In-View 模式)。

Answer 1

有一些选项可以控制 EJB 的事务行为。通常他们有一个“需要一个事务”设置，所以如果一个 bean 被调用时有一个事务，那么这个 bean 的工作就包含在已经建立的事务中，否则一个事务将在 bean 返回时开始并完成。

在您的代码中，在进入 EJB 时没有任何事务，因此正如您在从 EJB 返回时所说的那样，任何事务都已解决。

虽然这看起来可能存在问题，因为您可能会得到不一致的数据 View ，但我认为这种行为是可取的。我们希望在事务中花费的时间很短 - 否则数据库锁会持有很长时间，因此并发性会受到影响。

EJB 层应该被视为提供原子服务并相应地设计和使用。我不知道我是否正确地阅读了您的代码，但是对 Header 和 Body 使用单独的访问方法可能不是最好的设计。如果您需要 header 和正文之间的一致性，则在一次调用中获取所有数据可能更可取，并且实际上在单个数据库交互中更有效地完成。

--添加---您已经在您的问题中澄清，您确实关心屏幕不同部分之间的一致性，如果使用简单的 JSF 技术编码将使用单独的事务。

在我看来，当这种不一致极不可能或不可避免时，默认的 JSF 方法是合适的。例子:1).不太可能:查询历史数据，昨天的交易总额和昨天的交易列表。在历史无法更改的系统中，此类单独的查询将是一致的。2).不可避免:摘要来自一个系统，细节来自不同的系统，两个系统之间没有事务协调，我们无法保证一致性。我们只需要向用户显示这两个 View 可能略微不一致的迹象。

在你真正想要一致性的地方使用不同的方法，在一个请求中获取所有数据并保存它(比如在 session 或请求中)然后在两个 View 中使用它 - 如果你关心 View 不应该获取自己的数据关于这些事情。

我认为您会发现尝试使用事务来保持一致性会增加相当大的复杂性并影响吞吐量。跨 View 协调事务的问题在于没有简单的“所有者”，如果您重构页面，您将需要更改逻辑