seam中的并发模型

1）seam的并发概述

Servlet和EJB规范都没有定义任何关于如何管理来自同一个客户端的并发请求的条款。 Servlet容器简单地让所有的线程并发运行，把线程隔离的任务交给应用程序代码。 EJB容器允许无状态组件并发访问，但如果并发访问一个有状态Session Bean,就会抛出一个异常。

旧式的Web应用程序是围绕细粒度的同步请求编写的，因此这种行为可能还OK。 但是对现代的程序而言，由于大量使用了很多细粒度的异步（AJAX）请求，并发是实际存在的，并且必须被程序模型支持。 Seam在其上下文模型中加入了并发管理层。

Seam Session 和应用上下文是多线程的。Seam允许在一个上下文中并发请求，并发处理。事件（Event）和页面（Page）上下文自然是单线程的。 业务流程（business process）上下文严格而言是多线程的，但实际情况中并发很少见，因此大多数情况不会出现并发。 最后，Seam为Conversation Context提供了 每对话每进程单线程 模型，这是通过把同一个长时间运行的对话上下文中的并发请求序列化实现的。

因为Session上下文是多线程的，并且经常包含冲突的状态，所以Session范围内的组件总是被Seam保护以防止并发操作。 Seam默认把针对Session范围的Session Bean和JavaBean的请求序列化（并且检测、解决任何发生的死锁）。 对Application Scoped的组件来说，这却不是默认行为，因为Application Scoped的组件通常不会包含冲突的状态，并且在全局级别进行同步代价 极为 高昂。但是，你可以强制对任何Session Bean或JavaBean组件采用序列化的线程模型，要做的就是加上 @Synchronized 注解。

并发模型意味着AJAX客户端可以安全的使用冲突的Session和Conversational状态，并且不需要开发者做任何特别的工作。

 2）经验总结

数据字典是Application Scoped级别的，给类增加 @Synchronized