OAF—状态管理2

页面上下文
每次接收到一个页面的请求，OAF都建立一个OAPageContext存储信息，直到新的页面完成（特别的，OAPageBean建立OAPageContext，它主要是在页面后台起做作）
请求和页面边界
一个WEB应用的工作单元是一对请求／响应， 浏览器发送请求，servlet处理这个请求并返回一个响应，响应的传送意味着一个请求的结束，或者是一个请求的完成与新的请求之前的分界。
同样，当OAPageBean完成页面的处理，这也是当前页面与新页面之间的分界。
所以，一个用户从页面X跳转到页面A，又跳转到页面B，这时我们有两个请求边界：X和A之间，A和B之间。也有两个页面边界：X和A，A和B。

有些情况下，请求和页面的边界不相同，考虑以下情况：
用户从X到A
在A的时候，在响应决定显示哪个页面之前，用户选择了A的控件，所以，浏览器发送了一个请求到A，当A处理结束，就达了第一个页的边界。
在页面A的代码中，开发者估算用户选择了哪个控件发送JSP FORWARD到页面B，因为我们不想重新显示A，所以不用反回HTTP响应，OAF开始处理页面B（包括建立一个新的OAPageContext），一旦B处理完成，就到达了第二个页面边界。
因为页面B必须显示给用户，故一个HTTP响应发送到浏览器，就到了请求的边界。

基于以下的原因，明白这一点是很重要的
l 请求参数存在于请求的生命周期中，它可以跨越多个页面的边界。这对于那些认为一个请求和一个页面相同的开发者来说有点奇怪，在JSP FORWARD后也不用说明请求参数还存在。如以下示例：
1. 用户选择了页面X中的连接，转到页面A，页面A的URL包括参数foo=bar
2. 页面A发送一个到页面B的JSP FORWARD，现在即使我们是在一个新的页面中，请求中仍然包括foo=bar
3. 如果你不想在 jsp forward后还包括参数，你必须显式的覆盖它（注意你不能从请求中删除参数），如当你调用OAPageContext的setForward方法时你可以重置参数，foo=X
提示：将不需要的参数设为一个新值更可取，不要简单地将它设为“”。
l 因为在页面上下文与请之前没有一对一的关系，对于从OAPageContext中访问请求参数，有人会感到疑惑。只要记得每个页面是一个明确的实体，从它的“显示点”OAPageContext表示了一个请求。
l 当你进入上图的细节时，你会看到页面与请求的边界是明确的有不同含义的钝化事件点。
请求
尽管是生命周期很短，每个HTTP请求还是建立一个对象。这个对象包括以下应用状态：
所有的URL参数，不管是POST还是GET。
如果是POST请求，包括FORM中的数据。
如果是POST请求，web bean和事件名称会关联到用户选择的控件（如用户选择了一个GO按钮，请求会包括以这个按钮命名的web bean，所以你可以知道它被按下了并以此做出响应）。
为了访问请求值，使用OAPageContext的getParameter*()方法。
使用隐藏域
一个隐藏域是开发者在FORM中读取或写入数据工具，它不能被用户访问。如同用户看到的FORM域一样，隐藏域也在提交时被加到了请求中。
你可以通过在Jdeveoper中选择item style的formValue建立一个隐藏域。在运行时，它以oracle.apps.fnd.framework.webui.beans.form.OAFormValueBean来初始化。
在JSP FORWARD和重定向时指定值
当你显式的使用OAPageContext setForward*()或者OAPageContext.sendRedirct()方法转到一个新的页面时，你可以设定请求参数。
例如：假定有一个页面包括一个提交按钮，当用户点击时，我们想使用JSP FORWARD转到B页面。页面A需要一传递一个mode值给页面B（可以由不同的方式来访问），所以它知道如何做。
1、 用户点击提交按钮。
2、 在页面A的控制器中处理这个按钮，在processFormRequest方法中调用OAPageContext.setForwardURL()。做为一个方法调用，设定参数queryMode=automatic。
3、 在页面B的控制器中，在processRequest方法中检查参数queryMode值，调用getParameter(“queryMode”)。
4、 页面B控制器于是响应queryMode参数值为automatic，查询数据来显示页面。
调用OAPageContext.putParameter()指定值
OAPageContext包括putParameter()方法，在页面处理过程中，你可以用来传递值到web bean结构中，或者使用jsp forward从一个页面传到下一个页面。如：一个顶层的region可能放置一个值到缓存中，它的子region可以引用。
提示：这个和JAVA SERVLET 2.1的HttpServletRequest.setAttibute()方法很相似，可以认为它们做用相同。
设定URL参数
当在Jdeveloper中定义URL时你可以指定请求参数，或者在相关的程序中设置URL。
警告：URL是有长度限制的，你应该小心的添加URL参数的数量，尤其是很长的时候。因为URL是可见的，你应该加密敏感的值，然后再解密。
状态钝化模型（“Passivation”）
OAF是事务导向的，许多事务都跨越了多个页面。这些事务需要一定的状态来保存信息直到用户完成任务。如：一个建立采购定单的的流程中，用户在第一页描述 定单，在第二页输入一个或多个项目，在第三页提交前检查信息，这个采购定单数据在每个浏览器提交的请求之间必须被保存。
HTTP协议是无状态的，它不能保存任何指定的状态也不保证支持状态保存。而且，如果提供servlet session的JVM实例失败了，或者servlet session超时了，应用状态就丢失了，等待的事务也不能恢复。
OAF，从另一方面来讲，当用户工作时，合并了保存与恢复客户端状态的能力，即使是servlet session超时（以后的版本会提供JVM失败的支持）。
l 保存应用状态到另一个地方（在OAF中，是保存在 数据库中）叫做钝化。
l 从其它地方恢复应用状态叫做活化。
特别的，OAF目前提供了以下的状态管理特点：
可变的应用，当资源消耗很高时，OAF保存空闲线程的状态，并将它们的资源重新分配给其它线程，而不是新建一个资源实例。当空闲的线程激活时，保存的状态被恢复。简单说，资源会在JDBC连接、application modules、用户session中重新分配。
Servlet session 超时恢复，servlet session会超时，而不用用户重新开始一个未完成的事务（将来这个特点会扩展到提供中间层的失败支持）。
Application module 缓冲池
为了提高性能和可变性，OAF缓冲了APPLICATION MODULE，重用是比重建更有效的方式。在简单的情况下：
l 每个JVM都有一个application module池管理器，里面包含和管理不同的application module池。
l 每个application module池包含了一些application module的实例，如，如果一个应用使用了两个root application module，就有两个application module池：oracle.apps.fnd.framework.toolbox.tutorial.server.Lession3AM和 oracle.apps.fnd.framework.toolbox.tutorial.server.Lession4AM，如下图。换句话说，每个 root application module都建立一个池。
l 在池中的application module实例被设计成可用的或者不可用的（当前被提取走的）。
l 只有root application module是放在池中的，嵌套的application module是被root application module缓冲的。[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/122642/viewspace-1055488/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/122642/viewspace-1055488/