为什么是无状态会话 bean? [英] Why Stateless session beans?

问题描述

我正在阅读有关无状态会话 bean 的信息，但无法理解它的用途.

I was reading about stateless session bean and couldn't understand it's use.

摘自下面的太阳教程

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

"..Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients"

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

Where stateless session bean is being used? what kind of applications use it?

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

What mechanism has been being used before the advent of 'stateless session bean' to support multiple clients in the similar contexts?

谁能提供一些详细信息?

Can anyone please provide some details?

谢谢！

推荐答案

老实说，很难为 SLSB 找到任何合理的用例.由于它们不持有任何状态(如名称所示)，因此它们本质上应该是线程安全的.即使它们被容器池化.

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;
  }
}

客户端:

@Resource
private Slsb slsb;

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

这段代码(尽管它很粗俗)非常好，例如它不需要 AtomicInteger.

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

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

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.

这篇关于为什么是无状态会话 bean?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！