zzEJB sessionBean的生命周期

【译】 Stateless Session Bean的生命周期

首先要强调的是session bean的生命周期是由容器控制的而不是应用程序控制的。

stateless session bean的初始状态是不存在（does-not-exist）状态。就是在容器还没有启动的时候。接下来的状态是进入准备池（method-ready- pool）状态。当容器启动后，它会在准备池（method-ready pool）中建立许多stateless session bean的实例。为了在池中建立一个实例，容器会进行一下的步骤：

1. bean被实例化（instantiated）
2. 容器注入到bean的SessionContext。Bean使用SessionContext来对容器查询，查询内容可以是bean的状态 （status）或者是上下文（context）
3. 当bean定义了元数据（metadata）的时候，容器会进行对应的依赖注入（dependency injection）
4. 容器接下来，如果bean里有定义的话，容器将会调用PostConstruct的回调方法。PostConstruct方法是用来初始化bean中使用 到的任何资源（resources），例如，这个session bean可能使用了JMS queue来发送消息。JMS使用的connection queue将会在PostConstruct方法中被初始化。在一个state less session bean的生命周期中，仅仅在从does-not-exist状态到method-only pool状态转换的过程中，PostConstruct方法会被调用一次。

接下来容器会调用bean中的business方法。对于方法的 调用可以来自于不同的客户端（client）。相反的，当一个客户端调用一个stateless session bean的方法时，method-ready pool里的任何一个实例都可以被容器选择来实现这个方法。

方法被调用后，容器可能会选择销毁这个bean实例或者当其他的客户端调用这个bean中某个方法的时候重用这个bean实例。

当 容器决定要销毁这个实例的时候，它首先会调用PreDestroy回调方法（如果你定义了PreDestroy方法的话）。PreDestroy方法被用 来整理动作，比如如果你在PostConstruct方法中建立了某个连接的话，会在这里被关闭。在state less session bean的生命周期中，PreDestroy方法仅仅会在当向does-not-exist状态转换时被调用一次。

这种实例池和实例共享的方式意味着，对于stateless session bean来说，当有大量客户端访问的时候，它是具备良好的伸缩性的。

下图是从网络上找到的一副流程图，仅供参考

 

 

=============================================

 

【译】 stateful session bean的生命周期

stateful session bean的生命周期与stateless session bean有很多不同的方面。对于同一个bean的实例，没有池的概念，因为每一个实例仅仅为一个客户端服务。当客户端执行了一个借口的查找 （lookup）或者对一个bean进行依赖注入的时候，stateful session bean就会从does-not-exist状态转换为method-ready状态。所以，这一步是有客户端初始化的，而不是容器来初始化的。一旦 stateful session bean处在method-ready状态的话，容器就会同处理一个在method-ready状态的stateless session进行同样的操作：

1. bean被实例化（instantiated）
2. 容器注入到bean的SessionContext。Bean使用SessionContext来对容器查询，查询内容可以是bean的状态 （status）或者是上下文（context）
3. 当bean定义了元数据（metadata）的时候，容器会进行对应的依赖注入（dependency injection）
4. 容器接下来，如果bean里有定义的话，容器将会调用PostConstruct的回调方法。

接下来容器就会调用bean的一个方法了。

当客户端在不同方法调用的过程中，决定先等待一段时间或者进行其他的一些操作的时候，session就会处于停滞状态。容器的缓存可能会被停滞状态 的stateful session bean所占满。为了避免这种情况，容器会将它们从缓存中转移到磁盘或者其他的存储介质中。这个过程叫做钝化（passivation）并且会将bean 实力进行序列化。当客户端想要调用一个钝化的bean中的一个方法的时候，容器就会反序列化之前保存的bean然后调用对应的方法。这个过程被称为激活 （activation）。需要注意的是，所调用的方法可能并不在原始的那个bean实例中了，但是这样做是安全的，当激活的时候，我们重新恢复了在钝化 的时候存储的状态（state）。

钝化（passivation）算法是依赖与容器的，并且主要是依赖于像在容器的缓存中最多能够容纳的bean的数量，bean的最大的停滞时间， 或者是容器选择消灭哪一个bean的规则。

bean可以提供一个@PrePassivate回调方法，以供在钝化（passivation）前被迅速执行，和一个@PostActivate 回调方法，以供在激活后被迅速执行。一个session bean的状态可能会包含开放的资源，比如开放的sockets，数据库或者JMS链接，这些资源在钝化的时候容器是不能掌控的。那么在这种情况下，这些 资源就会在@PrePassivate方法中被关闭，并且在@PostActive方法中被重新打开。

当@Remove定义的方法被调用时，bean的状态就会从method-ready转换为does-not-exist状态。在配置的超时时间到 达的时候，bean也会进行这样的操作。在以上任何一种情况下，@PreDestory方法会首先被调用。

一个钝化后的bean同样会在超时后转移到does-not-exist状态。需要注意的是，这种情况下，任何的@PreDestory方法都不会 被执行。