blocks|key|1046309|text|1)您的EJB/Pojo确实不知道其中的区别。作为开发人员，您可以这样做，但是在代码级别上，无状态bean看起来很像一个状态bean。生命周期和回调实际上是相同的，区别在于客户端对该生命周期有更多的控制权，而对于无状态bean，容器可以控制该生命周期。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1046310|2)客户端只需维护会话Bean实例的副本。因此，例如，在web容器中，您可以简单地将实例填充到会话中。您不想做的就是继续为每个请求注入一个重要的会话bean+(使用@EJB)，因为每次都会创建一个新的会话bean。最好检查您的会话，如果它不存在，然后正常查找它。|1046311|3)状态bean可以有一个带有@Remove注释的方法。当您调用此方法时，bean将被销毁。如果不调用此方法，则容器具有超时功能，它将在某些配置的持续时间后自动获取会话bean。没有人期望一个重要的bean能够在服务器重新启动后存活下来(尽管在集群环境中，这个契约可能是不同的)。|1046312|还有一堆遗留的EJB+2行为大部分都能工作，你只需要跳过一圈就可以得到它，现代的东西就更容易了。|1046313|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

1) Your EJB/Pojo really doesn't know the difference. You as a developer do, but at the code level, a Stateless bean looks pretty much like a Stateful bean. The life cycles and callbacks are effectively the same, the distinction is that the client has more control over that lifecycle, whereas with a Stateless bean the container has control over that lifecycle.

2) Your client simply maintains a copy of the Session Bean instance. So, for example, in a web container you can simply stuff the instance in to the session. What you don't want to do is simply continually inject a Stateful Session bean (using @EJB) for every request as this will create a new one each time. It's better to check your session, if it does not exists, then look it up normally.

3) Stateful beans can have a method annotated with @Remove. When you call this method, the bean is destroyed. If you do not call this method, the container has a timeout facility that will reap the session beans automatically after some configured duration. There is no expectation of a Stateful bean surviving a server restart (though that contract may well be different in a clustered environment).

There's also a bunch of legacy EJB 2 behavior that mostly works, you just have to jump through hoops to get to it, the modern stuff is easier.

blocks|key|1046336|text|如果在无状态会话Bean中有实例变量，则它们的值将毫无意义(实际上)。这是因为您永远不知道将从实例池中检索无状态会话Bean的哪个实例来服务请求。|type|unordered-list-item|depth|inlineStyleRanges|entityRanges|data|1046337|无状态会话Beans只有在容器决定杀死它们时才会死。它们会根据需要被实例化，并且只有当容器决定销毁它们时才会被销毁(例如，如果它决定使实例池更小)。您说您假设它们在请求后被销毁，但这是不正确的。在请求之后，它们将返回到实例池，并随时准备为下一个请求提供服务。|1046338|unstyled|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|H|8|@]|9|@]|A|$]]|$1|D|3|-4|5|E|7|I|8|@]|9|@]|A|$]]]|F|$]]

<ul>
<li>If you have instance variables in a Stateless Session Bean, their values will be meaningless (practically speaking). This is because you never know which instance of a Stateless Session Bean will be retrieved from the instance pool to service a request.</li>
<li>Stateless Session Beans only die when the container decides to kill them. They are instantiated as needed, and will only be destroyed if the container decides to destroy them (for example if it decides to make the instance pool smaller). You say that you assume they are destroyed after the request, but this is incorrect. After the request they are returned to the instance pool and remain ready to service the next request.</li>
</ul>

blocks|key|755413|text|关于核心问题“我的POJO设计在@Stateless与@无状态之间有何不同”：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|755414|hello示例是@无状态会话bean的一个很好的例子:实现没有状态(没有类实例变量)。它对国家不作任何假设。如果您确实需要@无状态bean中的“更多信息”--查找它，(重新)计算它，等等。如果您打破了这条规则并在bean上定义实例变量，您就无法保证在每次调用bean时，这些信息都是您期望的信息:不要这样做。|755415|@+state的设计将保持容器将保存的内部状态(类实例变量)；bean必须是可序列化的。有非常真实的运行时间开销(内存，以及管理围绕第二个切线问题的问题，特别是在集群环境中)，与在会话的生命周期中保持bean相关--所以只在适当的情况下使用它(这证明@无状态bean的存在是合理的)。|755416|例如，考虑一个简单的注册页面:输入用户名、电子邮件地址等，然后是“您确定”？@Stateful可以保存这个临时信息，直到您准备好将其提交到后端为止。|755417|以谷歌为例；以下是一个例子：Example.html|offset|length|755418|客户端如何映射到正确的@Stateful确实取决于实现(而不是规范)，但是您可以预期它的管理方式类似于Servlet会话信息的维护方式。尽管如此，不要将Servlet会话与@+Session混为一谈--它们根本不是一回事。|755419|对于Java+5/6，在@Stateful中用@Remove注释一个方法，当客户端调用该方法时，它将被释放回乙醚。除此之外，只要您持有对@Stateful的引用(即在Servlet会话中)，您就可以预期在需要时@Stateful就会出现。|755420|另见：http://docs.oracle.com/javaee/5/tutorial/doc/bnbmt.html|755421|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6/html/Beta_Documentation/Stateful_Session_Bean_Example.html|1|http://docs.oracle.com/javaee/5/tutorial/doc/bnbmt.html^0|0|0|0|0|E|C|0|0|0|0|3|1J|1|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@$J|16|K|17|1|18]]|A|$]]|$1|L|3|M|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1A|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@$J|1C|K|1D|1|1E]]|A|$]]|$1|R|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]|Z|$5|U|V|W|A|$X|10]]]]

Regarding the core question "how does my POJO design differ between @Stateful beans vs. @Stateless":

Your hello world example is an excellent example of a @Stateless session bean: the implementation has no state (no class instance variables). It makes no assumptions about state. If you do need "more information" in a @Stateless bean look it up, (re)compute it, etc. If you break this rule and define instance variables on the bean, you have no assurance that the information will be what you expect it to be on each invocation of the bean: don't do it.

Your design of a @Stateful bean would keep internal state (class instance variables) that the container will preserve for the life of the bean; the bean must be Serializable. There are very real run-times costs (memory, and managing the issues around your second tangential question, particularly in a clustered environment) associated with keeping the bean around for the life of the session - so use this only as appropriate (which justifies the existence of @Stateless beans).

For example, consider a simple sign-up page: enter user name, email address, etc, followed by "are you sure"? A @Stateful bean can preserve this temp information until you're ready to submit it to a back end.

Google for examples; here's one: <a href="http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6/html/Beta_Documentation/Stateful_Session_Bean_Example.html" rel="nofollow">http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6/html/Beta_Documentation/Stateful_Session_Bean_Example.html</a>

HOW the client-side gets mapped to the correct @Stateful bean is truly implementation dependent (not spec'd), however you can expect that it's managed analogous to how your Servlet Session information is maintained. That said, don't confuse the Servlet Session with a @Stateful session - they're not the same thing at all.

For Java EE 5/6 in your @Stateful bean annotate one method with @Remove, and when your client calls that method it'll be released back to the ether. Outside of that, as long as you hold a reference to the @Stateful bean (i.e. in your Servlet Session) you can expect that @Stateful bean to be around when you need it.

See also: <a href="http://docs.oracle.com/javaee/5/tutorial/doc/bnbmt.html" rel="nofollow">http://docs.oracle.com/javaee/5/tutorial/doc/bnbmt.html</a>

blocks|key|755444|text|由于问题广泛，我将尝试回答，并提供更多的信息链接。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|755445|应用程序容器(在我的例子中是GlassFish)对EJB施加了哪些不同的限制，取决于它是否有状态？|offset|length|style|BOLD|755446|在您的情况下，主要区别是通过下列规格引文告诉您的：|755447|无状态会话bean是实例没有会话状态的会话bean。这意味着当所有bean实例不涉及为客户端调用的方法提供服务时，它们都是等价的。术语“无状态”表示实例对特定客户端没有状态。但是，实例的实例变量可以包含跨客户端调用的方法调用的状态。这种状态的示例包括打开数据库连接和对企业bean对象的对象引用。|blockquote|755448|在@的情况下，来自同一个用户/客户端的客户端请求如何映射到正确的bean+(从以前的请求中维护客户端状态的bean)？|755449|在客户端，您必须存储对有状态会话bean的业务接口的引用。从EJB容器中获得的这个对象。它是容器创建的对象，包含有关如何定位服务器端对象的详细信息。有关GlassFish中这些代理的一些信息可以从以下站点找到：|755450|会话bean什么时候死？我假设它是在对@无状态的请求完成后立即完成的，但对于@Stateful.却没有任何线索。|755451|不，无状态会话bean+(SLSB)不会在请求后死亡。无状态会话bean的生命周期是：|755452|它是在容器决定时创建的。在使用它之前，这是很自然的，但否则它就在容器的手中。在创建SLSB之后，它被放置在池中。|ordered-list-item|755453|当某些客户端需要调用SLSB中的方法时，在方法调用期间，将从池中取出一个实例。方法调用完成后，实例将返回到池中。然后这个实例(包括其他实例)就可以为下一个客户端服务了。|755454|当容器决定调整池的大小时，SLSB的寿命结束。|755455|有状态会话bean+(SFSB)的生命周期大致如下：|755456|当JNDI查找或注入发生时，容器会创建新实例。|755457|在其生命周期内，SFSB可以服务器多个方法调用。它也可以被钝化(基本上存储在磁盘上以节省资源)并再次激活。|755458|当调用remove方法或超时(SFSB在一段时间内没有使用)时，SFSB的生命结束。容器通常具有实现特定的默认超时，并且超时也可以调整。在Java+6(EJB3.1)中，这个超时可以通过StatefulTimeout根据每个bean进行调整。|755459|此外，当系统异常发生时，会话bean的实例将被丢弃。系统异常是RuntimeException+(未标记为应用程序异常)或java.rmi.RemoteException。事实上，SLSB的实例被丢弃对客户端是透明的。下一次调用肯定由SLSB的其他实例提供。在SFSB的情况下，未来所有可能的业务方法调用都将失败，因为SFSB的服务器端实例不再存在。详细信息可以从EJB3.1规范第14章找到。|755460|对生命周期的明确和详细的描述可以从EJB3.1规范(4.6，4.7)中找到。Java+6教程中提供了比上面更详细的描述和图表。|755461|对设计的主要影响是什么：|755462|@Stateless
public+class+HelloStateless+implements+HelloRemote+{
++++@Override
++++public+String+getGreeting(String+name)+{
++++++++return+"Hi+"+%2B+name;
++++}
}


/**
+*+This+design+is+not+possible+for+Stateless,+because
+*+subsequent+calls+to+setName+and+getGreeting+can+be
+*+handled+by+two+different+instances.+For+stateful+it+
+*+is+fine,+because+we+use+one+exclusively+one+instance.
+*/
@Stateful
public+class+HelloStateful+{

++++private+String+name;
++++public+void+setName(String+name)+{
++++++++this.name+=+name;
++++}

++++public+String+getGreeting()+{
++++++++return+"Hi+"+%2B+name;
++++}
}|code-block|syntax|javascript|755463|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javaee/6/api/javax/ejb/StatefulTimeout.html|1|http://docs.oracle.com/javaee/6/tutorial/doc/giplj.html^0|0|0|1D|0|0|0|2|1L|0|0|0|1C|0|0|0|0|0|0|0|0|2L|F|0|0|0|12|8|1|0|0|0^^$0|@$1|2|3|4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1V|8|@$D|1W|E|1X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|20|8|@$D|21|E|22|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|23|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|24|8|@$D|25|E|26|F|G]]|9|@]|A|$]]|$1|S|3|T|5|6|7|27|8|@]|9|@]|A|$]]|$1|U|3|V|5|W|7|28|8|@]|9|@]|A|$]]|$1|X|3|Y|5|W|7|29|8|@]|9|@]|A|$]]|$1|Z|3|10|5|W|7|2A|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|2B|8|@]|9|@]|A|$]]|$1|13|3|14|5|W|7|2C|8|@]|9|@]|A|$]]|$1|15|3|16|5|W|7|2D|8|@]|9|@]|A|$]]|$1|17|3|18|5|W|7|2E|8|@]|9|@$D|2F|E|2G|1|2H]]|A|$]]|$1|19|3|1A|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2J|8|@]|9|@$D|2K|E|2L|1|2M]]|A|$]]|$1|1D|3|1E|5|6|7|2N|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|1H|7|2O|8|@]|9|@]|A|$1I|1J]]|$1|1K|3|-4|5|6|7|2P|8|@]|9|@]|A|$]]]|1L|$1M|$5|1N|1O|1P|A|$1Q|1R]]|1S|$5|1N|1O|1P|A|$1Q|1T]]]]

Because questions are wide, I will try to answer shortly and provide links to additional information.

What different restrictions does the app container (in my case GlassFish) impose upon the EJB depending on whether it is stateful or not?

Main difference in your case is told with following quotation from specification:

<blockquote>
 Stateless session beans are session beans whose instances have no
 conversational state. This means that all bean instances are
 equivalent when they are not involved in servicing a client-invoked
 method. The term “stateless” signifies that an instance has no state
 for a specific client. However, the instance variables of the instance
 can contain the state across client-invoked method calls. Examples of
 such state include an open database connection and an object reference
 to an enterprise bean object.
</blockquote>

In the case of @Stateful, how does a client-side request from the same user/client get mapped to the correct bean (the one maintaining the client's state from a previous request)?

In client side you have to store reference to business interface of stateful session bean. This object you got from the EJB container. It is container created object that contains details about how to locate server side object. Some information about these proxies in GlassFish can be found from: 

When do session beans die? I assume its immediately after the request is done for @Stateless, but no clue for @Stateful.

No, stateless session bean (SLSB) do not die after request. Life of stateless session bean is: 

<ol>
<li>It is created when container decides so. This happens naturally in
some point before it is used, but otherwise it is in the hands of
container. After SLSB is created, it is placed to pool.</li>
<li>When some client needs to call method in SLSB, one instance is taken away from pool for duration of method call. After method call is finished, instance
is returned to pool. Then this instance (amoung others) is ready to serve next client.</li>
<li>Life of SLSB ends when container decides to adjust size of the pool</li>
</ol>

Life of stateful session bean (SFSB) is roughly follows:

<ol>
<li>New instance is created by container when JNDI lookup or injection happens.</li>
<li>During its life time SFSB can server multiple method calls. It can also be passivated (basically stored to disc to save resources) and activated again.</li>
<li>Life of SFSB ends when remove method is called or timeout (SFSB was not in use for some duration of time) happens. Containers usually have implementation specific default timeout and timeout can be also adjusted. In Java EE 6 (EJB 3.1) this timeout can be adjusted per bean basis via <a href="http://docs.oracle.com/javaee/6/api/javax/ejb/StatefulTimeout.html" rel="nofollow">StatefulTimeout</a>.</li>
</ol>

Additionally instance of session bean is discarded when system exception occurs. System exception is RuntimeException (that is not marked as application exception) or java.rmi.RemoteException. Fact that instance of SLSB is discarded is transparent to client. Next call will be for sure served by other instance
of SLSB. In the case of SFSB all possible future business method calls will fail, because server side instance of SFSB does not exist anymore. Details can be found from EJB 3.1 specification chapter 14.

Definitive and detailed description of life cycle can be found from EJB 3.1 specification (4.6, 4.7). Description more detailed than above and with graphs is available in <a href="http://docs.oracle.com/javaee/6/tutorial/doc/giplj.html" rel="nofollow">Java EE 6 Tutorial</a>.

And what is the main effect to the design of Hello service:

<pre><code>@Stateless
public class HelloStateless implements HelloRemote {
 @Override
 public String getGreeting(String name) {
 return "Hi " + name;
 }
}


/**
 * This design is not possible for Stateless, because
 * subsequent calls to setName and getGreeting can be
 * handled by two different instances. For stateful it 
 * is fine, because we use one exclusively one instance.
 */
@Stateful
public class HelloStateful {

 private String name;
 public void setName(String name) {
 this.name = name;
 }

 public String getGreeting() {
 return "Hi " + name;
 }
}
</code></pre>

With EJB (3.x) you have a choice of Session Beans: <code>@Stateful</code> and <code>@Stateless</code>. If I understand the basics behind these two options:

<ul>
<li><code>@Stateful</code> - Each user/client gets their own and is thus typically not pooled; maintains state across multiple requests</li>
<li><code>@Stateless</code> - Does not maintain state between requests and thus is usually pooled so each new client request gets a fresh bean</li>
</ul>

My core question here is quite simply, however there are several mini-questions that I have that are tangential to it: how does my POJO design differ between <code>@Stateful</code> beans vs. <code>@Stateless</code>? In other words, if I have a <code>HelloWorld</code> bean that implements the <code>Hello</code> interface, how does that POJO's design change depending on whether I want it to be stateful or not?

Tangential to this:

<ul>
<li>What different restrictions does the app container (in my case GlassFish) impose upon the EJB depending on whether it is stateful or not?</li>
<li>In the case of <code>@Stateful</code>, how does a client-side request from the same user/client get mapped to the correct bean (the one maintaining the client's state from a previous request)?</li>
<li>When do session beans die? I assume its immediately after the request is done for <code>@Stateless</code>, but no clue for <code>@Stateful</code>.</li>
</ul>

Thanks in advance for any clarity here.

How GlassFish maps client requests to sessions

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

使用EJB (3.x)，您可以选择会话Beans：@Stateful和@Stateless。如果我理解这两个选项背后的基本知识：@Stateful -每个用户/客户端都有自己的状态，因此通常不进行池化；在多个请求之间维护状态。@Stateless -不维护请求之间的状态，因此通常是池化的，因此每个新的客户端请求都会获得...

问GlassFish如何将客户端请求映射到会话
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GlassFish如何将客户端请求映射到会话EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GlassFish如何将客户端请求映射到会话
EN