EJB3:为什么要考虑实现细节的事务语义和状态性？

Question

事务语义和状态满足性是EJB3中的实现细节。实现可以决定是使用bean还是容器管理的事务。它可以决定容器管理事务的类型。它可以决定它是全状态的还是无状态的。

但是，从逻辑上讲，这些都是重要的接口细节。示例：(a)使用bean管理的事务的bean不能调用使用容器管理的事务的bean。(b)无状态bean不能调用有状态bean。

当使用EJB3接口时，您不知道它需要什么样的事务语义。同样，您不知道它是全状态的还是无状态的。您需要额外的实现细节。示例:文档。

在运行时，可以动态实例化不同的bean和调用链。因此可能会出现无效状态。现在-容器可以捕获这些情况；但为什么要等到运行时？

为什么事务语义和状态满足性要求不是接口的一部分？

Answer 1

在EJB3中，

事务语义和状态满足性被认为是实现细节。实现可以决定是使用bean还是容器管理的事务。它可以决定容器管理事务的类型。它可以决定它是全状态的还是无状态的。

我理解状态管理的观点，从客户端的角度来看，这确实很重要。

关于交易，这有点棘手。

• 事务的类型 (bean-managed或container-managed)是实现细节(我不确定您的示例(a))。
• propagation semantics不是。(required、mandatory、none等)。

Now -容器可以捕获这些情况；但为什么要等到运行时？

即使所有这些都是通过接口提供的，类型系统仍然不足以在编译类型中强制执行规则。

无论如何，您需要一个工具来根据它们的应用语义来检查这些约束。IDE可以解析注释，容器可以在部署模块时执行，更糟糕的是，它在运行时失败。

为什么事务语义和状态满足性要求不是接口的一部分？

java接口仅携带关于组件正确用法的有限信息集，可以是类、bean或。大多数组件的总体契约比在接口中公开的要复杂得多。

示例：

• Thread-safety:如果不查看文档，如何知道某个特定类是否是线程安全的？
• ContentHandler.characters()：如何知道每个XML标记可以多次调用它？
• 和其他列表...

我个人使用术语contract来指代完整的约束集。从类型系统的角度来看，接口只给出了方法的签名。

如果你对这个话题感兴趣，我建议你看看。更精确地将组件之间的契约形式化的想法由来已久。

所以我的回答是:因为即使是这样，你仍然需要更多的信息。