head first ejb(session bean)

session bean分为stateful bean与stateless bean, 主要分别为stateful bean可以保存当前服务对象的状态, 而且是每个服务对象都会有为自己服务的bean. stateless bean则不保存服务对象的状态, 只是根据服务对象所要求的操作提供服务, 可以为多个对象提供报务.

session bean要实现SessionBean, 然后加上自己的业务方法. 它是真正的业务服务的提供者(其实应当是POJO的EJB封装). 这些业务方法应该与其返回给客户的远程接口的方法名相同, 除了不能有RemoteException之外.

session bean生活在ejb容器的控制中, 处在ejb object的保护之下, 并不直接与所服务的客户进行交流. 对于一个session bean来说, 其生命周期主要由建立, 处理服务, 钝化, 激活与移除组成. stateful bean一般会完整的经历这些过程, 但对于stateless bean来说, 由于其不保存客户的状态信息, 所以没有钝化与激活这两个过程.

在客户要求某个服务后, 容器负责将对应提供服务的session bean建立. 顺序是constructor setSessionContext ejbCreate. 然后通过ejbPassivate与ejbActivate进行钝化与激活. 最后再通过ejbRemove通知bean将被移除.

容器 利用setSessionContext(SessionContext sc) 方法将自己的session context传给session bean, 使其可以通过SessionContext得到自己所在容器的事务/安全/资源等环境信息. 但在这个方法时, bean实际上还没真正在容器中成为session bean, 所以在这个方法中只能将对SessionContext的引用保存下来, 留给后面的方法使用. 当然在这个方法中, bean已经可以访问环境了, 比如使用jndi, 但不能使用jndi给出的对象. 所以个人认为还不如放到ejbCreate()中再说.

容器利用ejbCreate()方法通知bean它现在成为了session bean了. 这给bean一个机会, 在这个方法中真正的引用环境来初始化自己. 但在这个方法中, 由于不是对应的业务服务, 所以无法进行CMT方法的操作. 对于stateless bean来说, 只需要一个ejbCreate()方法, 而且容器也只会调用这个方法来进行通知. 而对于stateful bean来说, 可以提供多个ejbCreate方法, 而且这个方法可以以ejbCreateXXXX的形式存在, 当然对应的home就要声明成createXXXX的形式.

对于 stateful bean来说, 由于其保存了客户的信息, 所以不能同时对多客户提供服务, 如果它服务的客户在一段时间内没有要求其服务又不明确表示可以移除, 那么容器将会使用java的流机制对这个bean进行保存, 这一过程又叫钝化. 等到客户又有要求提供服务时再进行激活. 容器在进行钝化时, 会调用ejbPassivate()通知对应的bean. 而bean应当在这个方法中将其持有的不可流化的资源关闭,或使用自己的方法将其保存, 等到激活时再打开. 实际上由于容器对钝化的bean实行的是, 如果超时就将其抛弃的政策而不会调用ejbRemove, 所以在ejbPassivate时, 应当将不能被jvm的gc收集的资源关闭. 对于激活, 容器会通过ejbActivate()来通知bean, 所作的事情与ejbPassivate()相反.

容器在移除session bean时, 会调用ejbRemove(). 在这个方法里, session bean可以进行其的资源的释放工作. 而且j2ee的规范要求session bean不能有finalize方法, 所以只有这个方法可以进行让其进行这方面的工作了(其实ejbPassivate也要进行这方法的工作, 只是没这么明显而已). 但在下列情况下, 容器不会调用ejbRemove: session bean在钝化中超时, 容器崩溃, session bean的业务方法抛出了system exception(runtime exception). 这时, 资源的关闭就是你的问题了(汗, 真是规范定义者的风度啊).