EJB学习笔记(3)

 

    由于这段时间忙于结束现在的工作和找工作，所以很久没写日志了，今天先补上这一篇，这一次的学习笔记主要是针对《Mastering EJB》中的第4，5章讲session bean的部分。

      之前的笔记已经介绍过session bean的主要作用是处理一些业务流程，比如下定单，出货等等。这篇日志对session bean本身的用途和用法不想在花费任何笔墨，这里主要想将一下，session bean的实例池的管理。

      我在之前的一篇关于管理对象的日志中已经提出了池的概念，并举了一个静态池的例子，但是更多情况下我们遇到的是动态池。session bean的实例池的管理实际上就是一种池的管理办法。

      由于session bean分成stateful（有状态）和stateless（无状态）两种类型。所以就有分别针对这两种类型的管理方法。

      下面我先将一下什么是stateless和statefull。在许多情况下一次request的业务逻辑处理的请求是不包含任何状态信息的，也就是说请求的session bean根本不关心是谁在请求，他都以一样的方式处理。比如有个逻辑是验证当前登录用户的合法性，返回true或false来表示是否允许登录。这时在一次request结束后，那一次request的用户信息也就丢失了，因为没必要保留，下一次又来一次request他会将新传递的信息用以验证，然后又把信息丢失。这就是stateless的session bean。不过某些情况下则不然。比如你登录一个网上购物系统，然后选了一辆手推车，往里面加东西，这时候每一次的request都必须保持状态，因为你必须当前登录用户在这次购买之前，手推车里已经有了些什么东西。这就是stateful的session bean。至于究竟如何保持状态，那就不用程序员去关心了，一切自然都由容器完成（而事实上是容器记住了上一次调用的那个实例，有些信息甚至可能被记录在了外存上，所以能保持状态）。

      对每一个request都生成一个session bean的实例自然是愚蠢的做法，因此容器会采用实例池的办法去管理对象。事实上stateless的管理方法还是相当好理解的，因为他实际上是一个静态池，由于不记录会话状态，因此只需事先在容器提供商提供的部署文件中配置好一共需要维持多少个会话对象，就可以在系统中使用了。这里有一点很重要的是create并不代表真的就生成了一个会话bean的实例，只不过是容器通过实例池返回给了客户一个实例！事实上一切的生成操作都是由实例池代为管理了！

      对于stateful的实例池的管理就不是那么简单了，由于要记录会话的状态，事实上它是一个动态池。这里用到了activation（激活）和passivate（挂起）的思想，也就是说如果实例池的一个有状态会话bean长期不被调用的话他就会被挂起（注意，这只是一种策略），通常情况下是放到外存中（实际上是实现了 Serializable接口），而当一次request来了之后，并且需要的实例在挂起状态下，实例就会被激活。实际上，这和操作系统中，虚拟内存（页面文件）的机制是完全一样的，在一次的上下文切换（context switch）过程中，会发生swapped in和swapped out，只不过对于ejb来说，swapped in和swapped out的是对象（当然其实本质上还是内存）。那么究竟什么时候该激活，什么时候该挂起呢。书中表示大多数容器对于激活采取just in time的策略，即一旦需要（请求发生）马上激活（需要的话），而对于挂起，则是LRU（last recently used），如果达到了实例池所能维护的最大数量，并且还需要激活的话，会将最不常用的一个实例给挂起，以给要激活的实例腾出位置来。

      这就是实例池维护和管理session bean的大致机制了，这本书的第5章主要在介绍web services，包括wsdl和soap等概念。但是对于脱离于语言的更上一层的web services我，相信大家也不大能够接触到（一般情况下不大容易接触得到夸语言的系统集成）所以这里就不在介绍这本书的这部分内容了。