用户会话状态管理的另类方式：Oracle ADF BC AM的状态管理机制

ADF Business Component中的Application Module的状态管理

 

本文旨在简析Oracle ADF（Application Development Framework）中的Business Component中的Application Module运行时的状态管理原理。

ADF Business 简介：

ADF BusinessComponent以及JDeveloper简化了JEE应用的开发和交付过程。开发人员使用Oracle的ADF Business Component时，不需要将主要的开发工作放在编写应用的基础类代码上。ADF Business组件通过一系列可重用的软件组件和JDeveloper开发工具一起，使得这些工作完全可以图形化界面的配置方式来完成，大大节省了开发人员的时间并且通过标准化的开发模式减少了代码错误的可能性提高了开发效率和质量。

ADF BusinessComponent主要包含三大类组件：

Entity Object:

Entity Object对于于数据库表中的某一行记录（ORM）。可以通过各类DML来对该记录进行CRUD的操作。它也可以包含一些业务逻辑如：验证规则，UI显示格式等。Entity Object之间可以定义关系（1:n,n:n等）来映射到数据库表之间的关系。

View Object

View Object 封装了一条SQL查询以及其返回的结果。开发人员可以使用SQL语言包含的所有特性来定义一个View Object。并且View Object也可以创建关联关系来实现不同的master-detail的层级结构。View Object中可以对应零个或者多个Entity Object并且代理对Entity Object的CRUD。上层的代码需要使用View Object来实现最终用户对数据的操作需求。

Application Module

Application Module是事务性的组件，UI层的代码通过Application Module来访问下层的View Object，并且Application Module通常用于定义事务级的方法（或者服务级），对外作为一个业务服务的访问接口存在。其功能类似于EJB中的SLSB Façade模式。

这三类组件构成了ADF Business Component的主体。虽然这些组件包含了丰富的功能并且通过IDE实现了非编程式的开发，但作为标准的JEE的实现，开发人员还是可以对其进行扩展和客制化编程以满足最终用户的需求。

参考：关于ADF Business组件的详细说明请参看官方文档：http://docs.oracle.com/cd/E24382_01/web.1112/e16182/toc.htm

 

ADF BC AM的运行时状态管理

ADF BusinessComponent以下简称 ADF BC， Application Module以下简称AM。

在开发一个基于Http协议的JEE应用时，不可避免的需要将一些业务信息放在HttpSession中记录起来。因此，开发人员需要自己通过代码来实现对用户使用应用时状态的管理。一个典型的例子就是购物车对象。Oracle ADF BC的AM组件通过独特的管理方式，在MVC中的M层进行了状态管理，从而简化了开发JEE应用时的会话状态管理。

运行时AM的用户会话状态管理如下图所示：

a.     AM池 默认情况下，ADF的运行时会维护一个或者一些AM的实例池，每一个根节点的AM都会有一个独立的池（AM在定义时可以级联）。如果有新的用户访问，ADF框架运行时会从AM池中返回一个实例给当前线程中的Data Control。Data Control的实例会被一个ADF Binding Context实例所引用，该ADFBinding Context则会保存在HttpSession中。保存在HttpSession中的ADFBinding Context，都是轻量级的对象，占用很少的内存不会造成大的性能的影响。 同时，AM的实例池会维护每个session cookie token和AM实例之间的关系。

b.     重复使用AM实例 当下次有相同用户的request来的时候，会从AM池中返回上次其使用的AM实例以及其相关的状态（Entity对象，View对象的缓冲，View对象的查询条件，AM方法绑定的参数等信息）。这些状态在业务概念上可能是一个用户当前浏览的产品目录，购物车的ID，或者当前选择的数据库记录的某一行等。 AM通过在业务实现层的状态保存代替了通过Http Session保存业务数据的模式。AM在进行状态管理的过程中默认情况下不需要开发人员编写任何代码。如此，既实现了对用户会话的状态管理，又简化了开发人员的工作。

c.     Passiviation/Acitvation在一个高并发的场景下，AM池可能不得不将已经标记为有用户使用的AM实例提供给新的用户request，每个AM实例可能无法每次都能够等到上次服务的用户request（一般来说我们不会将AM的池设置为和最高并发数一样多，可能是最高并发数的20%，详见文档说明）。在这样情况下，AM就会将其状态passivate到一个数据表中。这些状态信息会以一个XML的形式存放。 通常在ADF的应用的数据库中会发现这样的一个表：PS_TXN。该表是ADF运行时自动创建的，当然需要连接的用户具有一定权限。DBA可以设定一些数据JOB来定期清理其中的数据。当原来的用户再次访问时，AM池就会将原来AM实例的passivation的数据从数据库中读回并装载到一个AM实例，这个过程称为Activation。通过这种方式，实现了AM的状态恢复。

d.     在集群环境下 我们会将jbo.dofailover参数设为true。这样为了保证AM状态的高可用性，在每次request结束时都会将AM状态做passivation。

 

AM其他相关信息：

AM实例可能的状态：

a.     Busy: 被一个user request使用中。

b.     Referenced: AM的状态被维护中，等待下次相同的用户request。也可以被任何其他request使用，如果必须的话。

c.     Unreferenced: AM在pool中，可以被任何request使用。

AM状态管理的持久化方式：

a.     Passivation = EO/VO的Snapshot被存放到数据库中。

b.     Recycle = reset:实例的状态被消除，并准备服务一个新的client

c.     Activation=将EO/VO的数据从数据库读回到AM。

 

·        在HA模式下passivation在每次request结束时进行，但recycle/activation并不会在每次request开始就进行。只有当服务器负载要求一个实例为新的客户端服务时才进行。每次做passivation 并不会马上对AM做recycle。Recycle只有在需要的时候才会进行。在非HA模式下，passivation会在负载需要的时候进行，并且紧接着会进行recycle和acivation。

 

·        默认情况下，每个AM都会引用一个数据库的连接，直到这个AM被destroy。因此在进行数据库连接池的配置时要确保每个AM会有足够的连接可用，因为默认情况下AM拿到连接后不会在每次request结束时释放的。ADF BC也提供了参数来改变这一默认行为，具体配置方式请参考开发手册。