当前位置：文江博客话题详情

为什么选择无状态会话 Bean？

发布于 2024-11-04 04:47:29 字数 246 浏览 1 评论 0原文

我正在阅读有关无状态会话 bean 的内容，但无法理解它的用途。

摘自下面的 sun 教程

“..因为无状态会话 bean 可以支持多个客户端，因此它们可以为需要大量客户端的应用程序提供更好的可伸缩性”

无状态会话 bean 在哪里使用？什么样的应用程序使用它？

在“无状态会话 bean”出现之前使用什么机制来支持类似上下文中的多个客户端？

有人可以提供一些详细信息吗？

谢谢你！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

青柠芒果 2024-11-11 04:47:29

老实说，很难找到 SLSB 的任何合理用例。由于它们不保持任何状态（正如名称所示），因此它们本质上应该是线程安全的。即使它们是由容器汇集的。

另一方面，人们很容易将它们用作安全的临时存储，因为它们保证是线程安全的（由于池化），您不需要任何同步或线程安全的集合。但是请考虑以下伪代码：

@Stateless
public class Slsb {
  private int counter;

  public void increment() {
    ++counter;
  }

  public int getCounter() {
    return counter;
  }
}

客户端：

@Resource
private Slsb slsb;

public void clientMethod() {
  slsb.increment();
  slsb.increment();
  slsb.getCounter();  //???
}

此代码（尽管很粗俗）非常好，并且不需要 AtomicInteger 等。

您期望什么结果？实际上，任何非负值都是可能的...对 slsb 的任何调用都可能由 Slsb 的不同实例提供，同时您的（以前使用的）实例可能有被用来服务不同的客户。结论：在 SLSB 中存储状态是错误的，但由于某种原因，SLSB 被池化以避免更改状态时出现线程问题（？！？）。个人我更喜欢单例服务（类似 Spring），我从来没有得到 SLSB 的想法。是的，我知道 EJB 3.1 中存在单例 EJB。

To be honest, it is hard to find any reasonable use case for SLSBs. Since they don't hold any state (as the name imposes), they should be inherently thread-safe. Even though they are pooled by the container.

On the other hand it is tempting to use them as a safe temporary storage as they are guaranteed to be thread-safe (thanks to pooling), you don't need any synchronization or thread-safe collections. But consider the following pseude-code:

@Stateless
public class Slsb {
  private int counter;

  public void increment() {
    ++counter;
  }

  public int getCounter() {
    return counter;
  }
}

Client-side:

@Resource
private Slsb slsb;

public void clientMethod() {
  slsb.increment();
  slsb.increment();
  slsb.getCounter();  //???
}

This code (despite its vulgarity) is perfectly fine and it does not require AtomicInteger for instance.

What result do you expect? Actually, any non-negative value is possible... Any call to slsb might be served by different instance of Slsb and in the meantime your (previously used) instance might have been used to serve different clients. Conclusion: storing state in SLSB is wrong, but for some reason SLSBs are pooled to avoid threading issues when changing the state (?!?). Personally I much prefer singleton services (Spring-like) and I have never got the SLSB idea. And yes, I am aware of singleton EJBs in EJB 3.1.

回复收藏 0 原文

禾厶谷欠 2024-11-11 04:47:29

使用过 EJB 3.0 后，我认为无状态会话 Bean 可以完善 Enterprise Bean 环境。它们确实是为您的其余业务逻辑设置一个外观。人们经常建议 SLSB 是线程安全的，但这至少可以说是一种误导。

当它们的代码路径包含调用非线程安全代码（例如共享的非线程安全缓存）时，它们绝对不是线程安全的。SLSB 提供的唯一保证是单个 SLSB 实例最多同时被一个线程使用。这基本上可以归结为 SLSB 具有同步方法访问，并且将有多个实例来服务客户端调用。但是，使用 SLSB 方法从这些多个实例中的共享非线程安全类调用代码仍然可能造成严重破坏，并且会使相关 SLSB 变得非线程安全。

由于 EE 上下文（事务、安全资源等）已经绑定到线程，我认为不需要 SLSB 而不是 Spring 单例。它们确实补充了纯 EJB 应用程序中的 Statefull Session beans。

在我看来，他们选择的 SLSB 路线和 EJB 3.1 的新锁并发设置是试图让程序员变得愚蠢，并让 Mighty Container 满足您的需求。帮自己一个忙，阅读《Java 并发实践》，并开始使用单例与常用的 Java 线程并发结构。（同步、易失、并发集合等）

回复收藏 0 原文

傾旎 2024-11-11 04:47:29

与这里大多数答案让您相信的相反，无状态性与类本身的线程安全性无关。这绝对不是@Stateless 的主要目标。开发人员本身仍然要对表示 @Stateless EJB 的类没有声明任何实例变量（即没有状态）负责。容器不负责该部分。基本上，开发人员必须说“嘿容器，这是一个无状态业务服务类，我将用 @Stateless 注释它，以便您可以将它用作无状态 EJB”，而不是相反左右。

如果你想要状态，那么使用@Stateful，每次客户端获取它时都会重新创建它（因此，如果客户端是一个视图范围的JSF托管bean，那么EJB将存活很长时间作为该 bean，或者如果客户端是会话范围的 CDI 托管 bean，则 EJB 将与该 bean 一样长地存在，等等）。或者，使用@Singleton，它基本上是应用程序范围的并且实际上是线程锁定的。

无状态和池化与事务的线程安全性有更多关系。您可能已经知道，默认情况下，@Stateless 上的单个方法调用算作单个完整事务。然而，由于所有敏感的预处理和后处理工作，该事务又需要特定 EJB 实例上的线程锁。因此，EJB 基本上可以阻止所有其他想要调用相同方法的客户端，直到事务提交为止。这正是它们按需克隆和汇集的原因。

请注意，@Singleton 不是池化的，并且默认情况下实际上是线程锁定的。现在您应该明白，当（ab）用作“无状态 EJB”时，@Singleton 默认情况下绝对不比 @Stateless 快。另请参阅 Java EE 7 教程“管理单例中的并发访问”会话 bean”。

另请参阅：

何时有必要或方便使用 Spring 或 EJB3 或全部一起使用？
JSF 请求作用域 bean 不断在每个请求上重新创建新的有状态会话 bean？
使用@EJB时，每个托管bean是否获得自己的@EJB实例？
< a href="https://stackoverflow.com/questions/33754603/ejb-asynchronous-method-to-retrieve-real-time-inserted-row-in-jsf/">EJB @Asynchronous 检索实时插入的行JSF 似乎是线程锁定的

In contrary to what most answers here let you believe, statelessness has nothing to do with threadsafety of the class itself. That's absolutely not the primary goal of @Stateless. The developer itself is still responsible for that the class representing a @Stateless EJB doesn't have any instance variables declared (i.e. no state). The container isn't responsible for that part. Basically, the developer must say "Hey container, here's a stateless business service class, I'll annotate it with @Stateless so that you can use it as a stateless EJB" and thus not the other way round or so.

If you want state, then use a @Stateful which will be newly recreated every time the client obtains it (so, if the client is e.g. a view scoped JSF managed bean, then the EJB will live as long as that bean, or if the client is e.g. a session scoped CDI managed bean, then the EJB will live as long as that bean, etc). Or, use a @Singleton which is basically application scoped and actually thread locked.

Statelessness and pooling has more to do with threadsafety of transactions. You probably already know that a single method call on a @Stateless counts by default as a single full transaction. However, that transaction in turn requires a thread lock on the specific EJB instance, because of all the sensitive pre- and post processing work. So the EJB could basically block all other clients wanting to call the same method until the transaction is committed. That is exactly why they are cloned and pooled on demand.

Do note that a @Singleton is not pooled and is by default actually thread locked. You should by now understand that a @Singleton is by default absolutely not faster than a @Stateless when (ab)used as a "stateless EJB". See also a.o. Java EE 7 tutorial "Managing concurrent access in a singleton session bean".