【译】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方法都不会被执行。