问题标签 [stateless-session-bean]

Java 中的无状态 bean 不会在来自客户端的两次调用之间保持其状态。所以简而言之，我们可以将它们视为具有业务方法的对象。每个方法都接受参数并返回结果。当调用该方法时，正在执行堆栈中创建一些局部变量。当方法返回时，从堆栈中删除局部变量，如果分配了一些临时对象，它们无论如何都会被垃圾回收。

从我的角度来看，这与通过单独的线程调用同一单个实例的方法没有什么不同。那么，为什么一个容器不能使用一个 bean 的实例而不是汇集多个实例呢？

我正在使用 EJB3（Hibernate + Glassfish 用于应用程序和 Web 服务层，Lift on Glassfish 用于 Web UI）在 Java 中开发多层金融处理应用程序，我正在努力解决在哪里的问题把我的业务逻辑。

当这个项目开始时，我们的第一个想法是将大部分业务逻辑放入无状态会话 bean。然而，随着时间的推移，我们发现 EJB 框架提供的依赖注入过于局限，所以我们的很多业务逻辑最终都在由 Guice 在无状态会话 bean 的 @PostConstruct 方法中组装的 POJO 中. 这一进展导致我们在会话 bean 和 POJO 之间的业务逻辑碎片化，我正在尝试找出一种方法来纠正这个问题。

最初，我们尝试让 Web 层使用会话 bean 的远程接口来执行一些可以从 UI 和 Web 服务层访问的功能，这些功能由 @WebService 注释的无状态会话 bean 提供。从持久性和性能的角度来看，这被证明是一场噩梦，因为我们的实体图可能会变得非常大，并且将分离的实体图重新附加到持久性上下文中非常容易出错，所以我们的解决方案是从传递对象开始周围的标识符并在需要时从数据库中查找实体。

我的基本问题是：您可以建议哪些原则和指导方针来决定业务逻辑应该放在会话 bean 中还是 POJO 中？给定一个复杂的对象图，什么时候传递实体 bean 才有意义？

我有一个使用 EJB 2.1 会话和实体 bean 的 J2EE 1.3 应用程序。目前，此应用程序在 JBoss 上作为 EAR 文件运行。由于 OSGi 提供的所有好处，我想切换到 SpringSource dm Application Server。

有谁知道是否有可以充当 EJB 容器的 OSGi 包？OpenEJB可以做到这一点吗？

我们多年前的 WebLogic J2EE 应用程序有一个使用无状态会话 bean 的消息驱动 bean。MDB onMessage 方法获取无状态会话 bean 的 home 接口，并调用 home 接口的create()方法来获取实际的无状态会话 bean 本身。

代码不会尝试缓存会话 bean，只是直接使用它：

MDB中没有对应remove()的调用。

我的问题是：在这种情况下不打电话是不是很糟糕remove()？

我相当确定需要调用remove()一个有状态的会话 bean，但是对于 state less 是否需要调用对我来说不太清楚。remove()

我们最近进行了显着的性能改进，但突然开始在负载下耗尽有状态会话 bean，但有以下异常：

我们的 MDB 池设置为：

我们的无状态会话 bean 池设置为：

我的问题是，调用create()无状态会话 bean 的 MDB 是否也负责调用无状态会话remove()bean ？（该应用程序似乎已经运行多年而没有调用，但我想知道提高吞吐量是否暴露了一个旧错误。）remove()

我正在从 J2SE 应用程序调用远程无状态会话 bean，并希望缓存对会话 bean 的引用以降低查找成本。这个可以吗？

在 EJB2 中，ServiceLocator 模式通常用于缓存对远程资源的查找，但 EJB3 没有单独的 EJB Home（通常被缓存）和 Remote 对象。

谷歌搜索，一个常见的答案是使用 EJB3 注入，但由于我正在从 J2SE 客户端调用远程 EJB 服务器，所以我不能使用注入。

我们有一个项目，其中包含相当数量的 EJB 2 无状态会话 bean，它们是很久以前创建的。这些不是我们的客户端通过 RMI 访问的第一行 bean，而是由该代码使用它们来执行特定功能。但是，我开始相信将它们作为会话 bean 根本没有任何好处。

• 它们不需要通过 RMI 访问。
• 它们不保留任何状态，它们只是从第一组 bean 中提取出来的代码，以降低它们的复杂性。
• 他们没有我们要换掉的多个不同的实现，每一个都像多年来一样（除非修复错误和添加功能）。
• 它们都没有改变从调用它们的 bean 进入它们的事务（即它们不需要新事务，不参与现有事务，或以其他方式改变事物）。

为什么这些不应该只是具有几个静态函数且根本没有 EJB 陷阱的类？

想象一个被大量使用的服务对象，它被实现为 EJB 2.1 SLSB，并且由于没有任何状态，它本身也恰好是线程安全的。它所有的公共方法都是事务性的（通过 CMT），最简单的需要一个事务，但有些需要一个新的事务。

如果我将此 SLSB 转换为真正的单例 POJO（例如使用 DI 框架），这将如何影响应用程序的可伸缩性？当服务是 SLSB 时，EJB 容器将管理一个实例池，每个客户端都可以从中获取自己的副本，所以我想知道将其转换为单例 POJO 是否会对该单个实例引入某种争用。

FWIW，此服务的方法都不是synchronized.

澄清：我将 SLSB 转换为 POJO 的动机是简化对象的生命周期（真正的单例与容器管理）和代码本身（一个接口和一个带注释的 POJO，与三个接口、一个 bean 类和一堆ejb-jar.xml 中的 XML）。

此外，FWIW，所讨论的服务是在 JBoss 3.x 上运行的并置 Web 应用程序的一个组件。

我有一个 EJB 定义如下：

当它部署到 Weblogic (WL) 时，它的名称为 myBean。我不确定这是否重要。

我尝试使用以下代码调用 bean：

有人知道为什么我会收到以下错误吗？

我有一个无状态会话 bean，它包含一个公共方法、几个私有方法和一些实例级变量。下面是一个伪代码示例。

我看到的是methodB正在打印没有传递给MethodA的值。尽我所能告诉它正在打印来自同一 bean 的其他实例的值。什么会导致这个？

我应该指出代码在 99.9% 的情况下都能按预期工作。但是，0.01% 给我带来了一些严重的问题/担忧。

我知道如果我有不同的公共方法，那么我可能不会在调用之间返回相同的 bean，这将导致这种行为。但是，在这种情况下，唯一的调用是对单个公共方法。容器（在这种情况下为 Glassfish）是否仍会在私有方法调用之间交换 bean？

（编辑）我将“类级别”重命名为“实例级别”，因为这引起了一些混乱。

通常我们将单例实例用于业务/ dao 层。在 EJB 的情况下，池化无状态会话 bean 的原因是什么？