SEAM学习笔记（一）-----------上下文相关组件模型

突然读到了很老的一句话，不动笔墨不读书。想想读书笔记的习惯一直没有养成，而确实之前学过的技术，做过的工程许久不翻就已经不记得了，毕业设计邱老要用SEAM+RICHFACES，没接触过，边看边学，记点东西以后备忘。

上下文相关的组件模型--Seam上下文（上下文的概念不是很清晰 ）

 

Stateless context

无状态，没太大意思，有不面向对象的争议，重要。

 

Event context

最窄的有状态上下文，web request上下文的泛化（generalize），其中与JSF相关的时间上下文比较重要，时间上下文相关联的组件在请求结束时被销毁，他们的状态至少在请求的生命周期中是存在并且是定义良好的

 

RMI或者Seam Remoting调用Seam组件的时候，一个时间上下文将为这个调用而被创建和销毁。

 

Page context

页面上下文允许将状态与一个渲染页面的实例 相关联，可以在Event Listener中初始化状态，或者在实际渲染页面的时候初始化状态。，任何源于该页面的事件都可以访问这些状态，对支持可点击列表这种功能时特别有用。

 

Conversation context

用户会话，跨越多个Serverlet，多个请求和多个数据库事务。

 

一些业务会话仅存在一次请求中。

跨越多个请求的业务会话必须通过Seam提供的anno注释

一些业务会话同时也是tasks。任务是一种业务会话，它特指一个长时间运行的业务会话，当正确完成后，可能会触发一业务流程状态的转换，Seam为任务划分提供了专门的注解。

 

业务会话是可以嵌套的

 

通常，业务会话是由Seam保存在Servlet Session中，跨越请求 ，Seam实现了可配置的conversation timeout，可以自动销毁不活动的业务会话，这就可以确保，如果用户取消会话，用户的登录Session中保存的状态不会无限增长。

 

长时间运行的业务会话中所产生的并发请求，Seam按顺序执行。

Seam也可以配置成把对话状态保存在客户端浏览器中。

 

Session context

保存与用户登录 session相关的状态，虽然当需要多个业务会话中交换状态的时候很重要，但是一般不建议使用session上下文保存组件，除非是登录用户相关的全局变量。

 

Business context

业务流程上下文保存了长时间运行的业务流程相关的状态

BPM引擎jBPM

生命周期通过外置的process definition language来定义，没有特别的注解来用于划分业务流程

 

Application context

即servlet中servlet上下文，保存的是静态 信息，如配置数据，引用数据或者元模型。

 

Context various上下文变量

 

context搜索优先级

组件实例是由特定的范围内取得的，其他的时候是通过优先级顺序在所有有状态范围内搜寻。 顺序为

  event page conversation session business process application

通过Context.lookupStatefulContexts()来执行带优先的搜索。

 

并发模型

 

Servlet和EJB都没有规范程序的并发请求该怎么处理

Servlet让所有的线程并发运行，把线程资源安全共享的任务交给代码

EJB允许无状态组件并发，当访问有状态session bean时，就会抛出一个异常。