来源：蜘蛛抓取(WebSpider)
时间：2016-03-15 04:22
标签：
违章停车怎么处理
966,690 六月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
Web开发必知的八种隔离级别
Web开发必知的八种隔离级别
James Leigh
注意:，500+CTO技聚重新定义技术领导力！
相关厂商内容
相关赞助商
更全的优惠信息，更多的免费活动，更丰富的线上课程，！
下面列出的隔离级别是用来帮助Web开发人员更好的理解他们编程模型中放置的约束，帮助系统架构师和开发人员共同讨论如何在保持必要的数据完整性的同时选择最有效的隔离级别。它们按照最少隔离（未提交读）到最多隔离（串行化）的顺序列出。
1、未提交读（Read Uncommitted）
未提交读隔离级别需要事务间很少的隔离。每一个读操作都能看到事务中等待的写操作（脏读）。然而已经提交的写操作必须要有一个串行顺序来防止脏写。悲观机制会阻塞有冲突的写操作直到其他写操作已经被提交或已经回滚。乐观机制不会锁住这些操作，它会允许所有的操作都通过。如果一个连接进行了回滚，那么接下来修改同一块数据的其他操作也会被回滚。在这种级别中，共享缓冲可以不加验证的进行使用。这种隔离级别最好在不需要事务（比如只读的数据集），或者事务只在独占数据库时才修改的情况下使用。
例子：一个只在离线情况下更新的档案数据库，或者不在事务中使用的审核/登陆（audit/logging）表。
2、已提交读（Read Committed）
已提交读可以读取系统中任何已经提交的状态，并且可以不加验证（混合状态）的进行缓冲，只需当前连接中发生的改变能够反映到结果中即可。悲观机制将其实现为单调视图。乐观事务则隔离存储所有的改动，使得它们直到提交后才可用。读已提交使用一个非常乐观的机制，它推迟写入所有的变化直到事务被提交为止。这种形式的乐观隔离可以在不阻塞读操作的情况下实现复杂的写入操作，并且它没有验证模式。共享缓冲只能在已提交的状态中使用。这种隔离级别最好在结果可以使用旧值，且事务只能用于写入操作的情况下使用。
例子：一个不必显示当前最新帖子的在线论坛，且它的帖子间数据不相冲突。
3、单调视图（Monotonic View ）
单调视图是对读已提交的一个扩展，它其中的事务在执行时会观察数据库中一个单调上升的状态。在这种级别中，如果有明显的写入事务，那么悲观事务会在读入操作中被阻塞。乐观事务会像在读已提交中一样操作，隔离保存所有的改动，并且会验证它们的缓冲以确保其仍然合法。这种级别可以定期地同步数据库副本，且最好在不需要事务或者仅存在写操作事务的情况下使用。
例子：一个仅能由一个人来修改的用户偏好表。
4、快照读取（Snapshot Reads）
快照读取扩展了单调视图，它可以保证查询结果都能反映到数据库一致的快照中。悲观机制会在读操作时阻碍其他影响结果的写入操作。乐观机制则允许其他的写入操作，并通知读取事务某部分已经发生改变并进行回滚。想要实现一个乐观机制，必须在读操作结束之前验证是否有什么并行的写入操作修改了结果，如果有的话，那么结果可能会重做或回滚。这个检验过程可能只是简单的检查同一张表中是否出现了写入操作，或者只是检查改动的查询结果。乐观隔离级别可以很轻松地检测出冲突，并且在允许并发读入操作的过程中，支持写入操作。这种级别只要能够读取到快照，便可以定期地同步数据库副本。最好在写入操作很少，不想与读入操作冲突，且查询结果需要一致性的时候使用这种隔离级别。
例子：：一个查询比修改频繁，且只保留最新值的货币换位表或者查询表。
5、游标稳定性（Cursor Stability）
游标稳定性隔离扩展了读已提交，并且是许多关系型数据默认的隔离级别。在这种隔离级别中，悲观事务如果在一个单独的语句中执行的话，必须得指定它将修改的记录。这通常可以在"SELECT"查询后附加“FOR UPDATE”关键字来实现。在这种情况下，其他冲突的读写悲观事务都将被阻塞直到该事务结束为止。乐观事务会跟踪提交时被验证的所有修改记录/实体的版本号。这是一种很流行的乐观隔离级别，因此被所有的主流对象关系映射库支持。在Java持久性API中，可以使用FLUSH_ON_COMMIT（尽管查询可能不影响本地改动）来接近达到这种级别，且如果检测到冲突的话，可以抛出OptimisticLockException 异常。这种隔离也同样可以用在HTTP头域的If-Match或者 If-Unmodified-Since中，它可以用来在更新前对比上一个资源的版本或者时间戳。这种级别最好在实体由外部信息（不从数据库中读取）更改，或者改动不会彼此覆盖的情况下使用。
例子：一个共享的公司目录或者一个wiki。
6、可重复读取（Repeatable Read）
可重复读取级别扩展了游标稳定性，它保证事务内的任何数据在事务过程中都不会被修改或者移除。悲观事务需要读取所有记录上的锁，并阻塞其他服务来修改这些记录。乐观事务则会跟踪所有的记录或者实体，并检查它们是否在提交时被修改过。这种级别最好在实体状态能够影响其他实体，或者事务由读写操作构成的情况下使用。
例子：一个订单跟踪数据库，它从一个实体中读取值并用它来计算其他的实体值。
7、快照隔离（Snapshot Isolation）
快照隔离扩展了快照读取和可重复读取，它保证事务中所有进行的读操作都能看到数据库中一致的快照。事务执行的的任何读操作都会有相同的结果，而不管它们在事务中执行的早晚。这和可重复读取不同，因为快照隔离能够防止幻读（查询结果不断变化）。许多关系型数据库采用多版本并发控制（也可以叫做 SERIALIZABLE）来支持这种级别，实现方法是通过锁和冲突检测的组合。在这种级别中，考虑到它可能与悲观机制或者乐观机制相冲突，因此事务一定要做好回滚的准备。悲观机制会通过锁住资源来尝试减少冲突的机会，但是必须在事务提交后将这些改动合并。乐观机制也会使用多版本并发控制，但是它不会阻塞其他可能产生潜在冲突操作的事务，反而是将冲突的事务进行回滚。这种级别的隔离最好在事务可以读取和修改多个记录的情况下使用。
例子：一个基于系统状态规则的工作流系统。
8、可串行性（Serializability）
串行性是快照隔离的扩展，它要求所有的事务都必须一个接着一个的出现，就好比它们被串行化过一样。悲观机制需要锁住所有评估过的查询，以防止写入操作影响这些结果。而乐观机制则跟踪所有评估过的查询，并在事务结束时使用一个后向验证或前向验证的模式来检查是否有并行写入操作影响了并行读入操作，如果有的话，它会将冲突事务外的所有事务进行回滚。在这种隔离级别中，任何提交事务都不会改变系统的表征状态。最好在需要完整数据一致性的情况下使用这个级别的隔离。
例子：一个进行范围查询来计算新值的账目系统。
下面是本文提到的隔离级别的汇总表，它可以帮助你找到最适合你应用程序的级别。
事务在不同隔离级别中可能的冲突类型：
游标稳定性
可重复读取
不同隔离级别的最佳前提：
乐观冲突模式
不能并发读写
没有冲突检测
单调的读/写
必须被验证
没有冲突检测
必须被验证
对比读入与修改内容
一致性读入
游标稳定性
对比修改的实体版本
可重复读取
对比读入的实体版本
必须被验证
对比读入的实体版本
必须被验证
对比查询与修改内容
完善数据一致性
数据一致性在数据库应用程序中至关重要-它允许开发者在分布式环境下使用数据。尽管强一致性级别如可串行性提供了一个简单的编程模型，但是它们会导致开销 过大，操作阻塞或者事务回滚，这对于很多应用程序来说都是不必要的。如果有其他问题的话，可以使用更加适当的隔离级别来帮助开发人员和系统架构师，让他们 在保持性能和开销平衡的前提下更好的理解数据一致性的需求。
查看英文原文：。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家加入到中与我们的编辑和其他读者朋友交流。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
不想多说什么
Zhang Gavin
文章质量相当的高
很多术语不是很清楚
.com gaotianpu
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 ©
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?Chapter&5.&事件、拦截器和异常处理Chapter&5.&事件、拦截器和异常处理
两个更深入的概念补充了上下文组件模型，这两个概念推动了极端松耦合这一Seam应用程序的独特特性。
第一个是强有力的事件模型，事件可以通过类似JSF绑定表达式的方法映射到事件监听器。
第二个是普遍使用注解和拦截器，这使我们总能跨越式地切入到到实现业务逻辑的组件。
5.1.&Seam事件
Seam组件模型是为使用 事件驱动的应用程序 而开发的，特别是在一个细粒度的事件模型里进行细粒度的松耦合组件的开发。
Seam的事件有几种类型，大部分是我们已经见过的：
JSF事件jBPM的状态转移事件Seam页面动作Seam组件驱动事件Seam上下文事件
所有这些不同种类的事件都通过绑定了表达式的JSF EL方法映射到Seam组件去。JSF事件是在JSF模板中定义的：
&h:commandButton value="Click me!" action="#{helloWorld.sayHello}"/&
对于jBPM的转换事件，是在jBPM过程定义或页面流定义中指定的：
&start-page name="hello" view-id="/hello.jsp"&
&transition to="hello"&
&action expression="#{helloWorld.sayHello}"/&
&/transition&
&/start-page&
你可以在其他地方找到更多关于JSF事件和jBPM事件的信息。我们现在主要关注由Seam定义的两种新增类型的事件上。
5.1.1.&页面动作
Seam的页面动作是指就在我们渲染页面之前发生的事件。我们在 WEB-INF/pages.xml 中声明页面动作。
我们可以为任何一个特殊的JSF视图id定义一个页面动作：
&page view-id="/hello.jsp" action="#{helloWorld.sayHello}"/&
或者，我们可以使用一个通配符 * 作为 view-id 的后缀来指定一个动作，应用到所有符合该模式的视图ID中：
&page view-id="/hello/*" action="#{helloWorld.sayHello}"/&
如果多通配符的页面动作匹配当前的view-id，Seam将按照从最通用到最特殊的顺序来调用所有的动作。
页面动作方法可以返回一个JSF的结果。如果这个结果非空，Seam将用定义好的导航规则导航到一个视图中去。
此外，在元素 &page& 里提到的视图id不需要对应一个真实的JSP或Facelets页面！
因此，我们可以再生传统的面向动作的框架的功能，就像Struts或WebWork使用页面动作那样。例如：
TODO: translate struts action into page action
如果你想要应non-faces的请求做点复杂的事情（例如HTTP GET请求），这就非常有用。
对于多页面或者条件页面的动作，可以使用 &action& 标签指定：
&page view-id="/hello.jsp"&
&action execute="#{helloWorld.sayHello}" if="#{not validation.failed}"/&
&action execute="#{hitCount.increment}"/&
&/pages&5.1.1.1.&页面参数
一个JSF faces请求（表单提交）同时封装了一个“动作action”（一个方法绑定）和“多个参数parameters”（输入值绑定）。一个页面动作也可能需要参数！
由于GET请求是可以做标记的，页面参数是作为人类易读的请求参数来传递的。（不像JSF form的输入，什么都有就是不具有可读性！）
你可以使用页面参数，带不带动作方法都可以。
5.1.1.1.1.&将请求参数映射到模型
Seam让我们提供一个值绑定，来将一个已命名的请求参数映射成一个模型对象的属性。
&page view-id="/hello.jsp" action="#{helloWorld.sayHello}"&
¶m name="firstName" value="#{person.firstName}"/&
¶m name="lastName" value="#{person.lastName}"/&
¶m& 的声明是双向的，就像一个JSF输入的值绑定：
当视图id的一个non-faces(GET)请求发生时，Seam在执行了相应的类型转变之后，就在模型对象上设置已命名的请求参数的值。
任何 &s:link& 或 &s:button& 透明地或者说自动地包括request带有的参数。
参数的值由渲染阶段（当 &s:link& 被渲染）的绑定值来决定。
使用 &redirect/& 到视图id的任何导航规则很明显是含有请求参数。
参数的值由调用应用程序阶段结束时的值绑定大小来决定。
这个值很明显是由带有视图id的被提交的任何JSF页面传播的。
这意味着视图参数表现得就像faces请求的 PAGE 范围内上下文变量一样。
最理想的情形是 无论 我们从什么页面到 /hello.jsp
（或者从/hello.jsp回到/hello.jsp），
在值绑定中被引用的模型属性的值都应该被“记住”，而不需要对话来存储（或者其他的服务器端状态来存储）。
5.1.1.1.2.&传播请求参数
如果只是指定 name 属性，那么请求参数就会利用 PAGE 进行上下文传播（它没有被映射成模型属性）。
&page view-id="/hello.jsp" action="#{helloWorld.sayHello}"&
¶m name="firstName" /&
¶m name="lastName" /&
如果你想要建立多层的复杂CRUD页面，页面参数的传递尤其有用。你可以用它“记住”你前面到过的页面（例如当按了保存按钮时）和正在编辑的实体。
很明显，如果参数是视图的页面参数的话，任何 &s:link& 或者 &s:button& 都会传播请求参数。
这个值很明显是由带有指定视图id的页面的任何jsf页面表单提交传播的。
（这意味着视图参数表现得就像faces请求的PAGE范围内视图参数一样。）
所有这些听起来很复杂，你可能会想这么一个外来的构造是否真的值得去努力。实际上，一旦你“掌握了它”，有这种想法非常自然。
理解这些资料显然需要花费时间的。页面参数是跨越non-faces请求来传播状态的最优雅方式。
对于用可标记的结果页，搜索屏幕的问题尤其有效，在这种情况下，我们喜欢可以写应用程序代码、用同一段代码来处理POST和GET请求。
页面参数消除了视图定义中请求参数的重复清单，并使得重定向更容易用代码实现。
5.1.1.1.3.&转换和验证
你可以为复杂的模型属性指定一个JSF转换器:
&page view-id="/calculator.jsp" action="#{calculator.calculate}"&
¶m name="x" value="#{calculator.lhs}"/&
¶m name="y" value="#{calculator.rhs}"/&
¶m name="op" converterId="com.my.calculator.OperatorConverter" value="#{calculator.op}"/&
或者：
&page view-id="/calculator.jsp" action="#{calculator.calculate}"&
¶m name="x" value="#{calculator.lhs}"/&
¶m name="y" value="#{calculator.rhs}"/&
¶m name="op" converter="#{operatorConverter}" value="#{calculator.op}"/&
JSF验证器和 required="true" 也可以这样用：
&page view-id="/blog.xhtml"&
¶m name="date"
value="#{blog.date}"
validatorId="com.my.blog.PastDate"
required="true"/&
或者：
&page view-id="/blog.xhtml"&
¶m name="date"
value="#{blog.date}"
validator="#{pastDateValidator}"
required="true"/&
更好的方式，基于模型的Hibernate验证器注解会自动被识别和验证。
当类型转换或者验证失败后，一个全局的 FacesMessage 就会被添加到 FacesContext 中。
5.1.1.2.&导航
你可以使用在Seam应用程序的 faces-config.xml 中定义的标准JSF导航规则。然而，JSF导航规则也有许多烦人的限制：
在重定向时，不可能指定一个将要使用的请求参数。
不可能由一个规则来开始或者结束对话。
通过给动作方法求取返回值来运作规则；不可能去给一个任意的EL表达式取值。
更深层次的问题在于”管理“逻辑在 pages.xml 和 faces-config.xml 之间是分散的。
最好是把这种逻辑统一进 pages.xml 中。
这个JSF导航规则：
&navigation-rule&
&from-view-id&/editDocument.xhtml&/from-view-id&
&navigation-case&
&from-action&#{documentEditor.update}&/from-action&
&from-outcome&success&/from-outcome&
&to-view-id&/viewDocument.xhtml&/to-view-id&
&redirect/&
&/navigation-case&
&/navigation-rule&
可以重写如下：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"&
&rule if-outcome="success"&
&redirect view-id="/viewDocument.xhtml"/&
&/navigation&
如果我们不必用字符类型的返回值（JSF的结果）来污染 DocumentEditor 组件的话会更好。
因此Seam允许我们写成：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"
evaluate="#{documentEditor.errors.size}"&
&rule if-outcome="0"&
&redirect view-id="/viewDocument.xhtml"/&
&/navigation&
或者甚至可以写成：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"&
&rule if="#{documentEditor.errors.empty}"&
&redirect view-id="/viewDocument.xhtml"/&
&/navigation&
第一种形式计算一个值绑定，来确定要被后面的一系列导航规则所使用的结果值。
第二种方法忽略结果，并为每个可能的规则来计算值绑定。
当然，当一个更新成功，我们可能想要结束当前的对话。我们可以这样做：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"&
&rule if="#{documentEditor.errors.empty}"&
&end-conversation/&
&redirect view-id="/viewDocument.xhtml"/&
&/navigation&
由于我们终止了会话，后面的任何请求都无法知道我们对哪个文档感兴趣。
我们可以将文档id作为一个请求参数传递，这样也使得视图变成是可标记的：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"&
&rule if="#{documentEditor.errors.empty}"&
&end-conversation/&
&redirect view-id="/viewDocument.xhtml"&
¶m name="documentId" value="#{documentEditor.documentId}"/&
&/redirect&
&/navigation&
在JSF中，null是一个特殊的结果。结果null被解释成“重新显示页面”。
下面的导航规则符合任何非null的结果，而 不符合 null的结果：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"&
&render view-id="/viewDocument.xhtml"/&
&/navigation&
如果结果出现null，你还想执行导航，就使用下面的形式：
&page view-id="/editDocument.xhtml"&
&navigation from-action="#{documentEditor.update}"&
&render view-id="/viewDocument.xhtml"/&
&/navigation&
view-id可以作为一个JSF EL表达式提供：
&page view-id="/editDocument.xhtml"&
&navigation if-outcome="success"&
&redirect view-id="/#{userAgent}/displayDocument.xhtml"/&
&/navigation&
&/page&5.1.1.3.&导航的定义、页面动作和参数的细粒度文件
如果你有很多不同的页面动作和页面参数，或者甚至是很多导航规则，你就会很想把这些声明分开放到多个文件中去。
你可以在一个名为 calc/calculator.page.xml 的资源中，为一个有着视图id /calc/calculator.jsp 的页面定义动作和参数。
这个例子中的根元素是 &page& 元素，隐含着视图id：
&page action="#{calculator.calculate}"&
¶m name="x" value="#{calculator.lhs}"/&
¶m name="y" value="#{calculator.rhs}"/&
¶m name="op" converter="#{operatorConverter}" value="#{calculator.op}"/&
&/page&5.1.2.&组件驱动的事件
Seam组件可以通过方法间简单的调用相互影响。状态组件甚至实现 Observer/Observable 模式。
但在组件直接调用彼此方法的时候，为了使组件在一个比可能存在的更加松耦合的方式下相互作用，Seam提供了 组件驱动事件。
我们在 components.xml 里指定了事件监听器（观察者）。
&components&
&event type="hello"&
&action execute="#{helloListener.sayHelloBack}"/&
&action execute="#{logger.logHello}"/&
&/components&
在这里，event type 是任意的字符串。
事件发生时，该事件已经注册过的动作将按照它们在 components.xml 中出现的顺序被依次调用。
组件如何发起事件？Seam为此提供了一个内置的组件。
@Name("helloWorld")
public class HelloWorld {
public void sayHello() {
FacesMessages.instance().add("Hello World!");
Events.instance().raiseEvent("hello");
或者你可以使用注解。
@Name("helloWorld")
public class HelloWorld {
@RaiseEvent("hello")
public void sayHello() {
FacesMessages.instance().add("Hello World!");
注意这个事件产生器没有依赖任何事件消费者。事件监听器现在可以完全不依赖于产生器而实现：
@Name("helloListener")
public class HelloListener {
public void sayHelloBack() {
FacesMessages.instance().add("Hello to you too!");
上述在 components.xml中定义的方法绑定关心把事件映射到消费者去。
如果你不喜欢 components.xml 文件中的那一套，可以用注解来替代：
@Name("helloListener")
public class HelloListener {
@Observer("hello")
public void sayHelloBack() {
FacesMessages.instance().add("Hello to you too!");
你可能想知道为什么在这个讨论中没有提到关于任何事件对象的东西。
在Seam中，对事件对象而言，不需要在事件生产者和监听器之间传播状态。
状态保留在Seam上下文中，在组件之间共享。然而，如果你真想传递事件对象，你可以：
@Name("helloWorld")
public class HelloWorld {
public void sayHello() {
FacesMessages.instance().add("Hello World, my name is #0.", name);
Events.instance().raiseEvent("hello", name);
}@Name("helloListener")
public class HelloListener {
@Observer("hello")
public void sayHelloBack(String name) {
FacesMessages.instance().add("Hello #0!", name);
}5.1.3.&上下文事件
Seam定义了许多内置事件，应用程序可以用它们来进行特殊类型的框架集成。这些事件是：
org.jboss.seam.validationFailed — JSF验证失败时被调用org.jboss.seam.noConversation — 没有长时间运行的对话在运行或者长时间运行的对话被请求时调用org.jboss.seam.preSetVariable.&name& — 设置上下文变量 &name& 时调用org.jboss.seam.postSetVariable.&name& — 设置上下文变量 &name& 时调用org.jboss.seam.preRemoveVariable.&name& — 未设置上下文变量 &name& 时调用org.jboss.seam.postRemoveVariable.&name& — 未设置上下文变量 &name& 时调用org.jboss.seam.preDestroyContext.&SCOPE& — 在 &SCOPE& 上下文被销毁之前调用org.jboss.seam.postDestroyContext.&SCOPE& — 在 &SCOPE& 上下文被销毁之后调用org.jboss.seam.beginConversation — 当一个长时间运行的对话开始的时候调用org.jboss.seam.endConversation — 当一个长时间运行的对话结束的时候调用org.jboss.seam.beginPageflow.&name& — 在页面流 &name& 开始时调用org.jboss.seam.endPageflow.&name& — 在页面流 &name& 结束时调用org.jboss.seam.createProcess.&name& — 在创建进程 &name& 时调用org.jboss.seam.endProcess.&name& — 在进程 &name& 结束时调用org.jboss.seam.initProcess.&name& — 在进程 &name& 与对话相关联时调用org.jboss.seam.initTask.&name& — 在任务 &name& 与对话相关联时调用org.jboss.seam.startTask.&name& — 在任务 &name& 开始时调用org.jboss.seam.endTask.&name& — 在结束任务 &name& 时调用org.jboss.seam.postCreate.&name& — 在创建组件 &name& 时调用org.jboss.seam.preDestroy.&name& — 在销毁组件 &name& 时调用org.jboss.seam.beforePhase — 在开始一个JSF阶段之前调用org.jboss.seam.afterPhase —
在一个JSF阶段结束之后调用org.jboss.seam.postInitialization — 当Seam被初始化并启动所有组件时被调用org.jboss.seam.postAuthenticate.&name& — 用户认证之后调用org.jboss.seam.preAuthenticate.&name& — 在尝试认证用户之前调用org.jboss.seam.notLoggedIn — 在不需要认证用户和需要认证的时候调用org.jboss.seam.rememberMe — 当Seam安全在cookie中发现用户名时发生org.jboss.seam.exceptionHandled.&type& — 在Seam处理未被捕捉的异常时被调用org.jboss.seam.exceptionHandled — 在Seam处理未被捕捉的异常时被调用org.jboss.seam.exceptionNotHandled — 在没有未被捕捉异常的处理器时被调用org.jboss.seam.afterTransactionSuccess — 当事务在Seam Application Framework中成功时调用org.jboss.seam.afterTransactionSuccess.&name& — 当管理具名 &name& 实体的事务在Seam Application Framework中成功时调用
　　Seam组件可以用它们观察任何其他组件驱动事件的同样方式来观察这些事件中的任何一种。
5.2.&Seam 拦截器
EJB 3.0为会话Bean组件引入了一个标准的拦截器模型。
要往Bean里添加拦截器，你需要写一个类，该类有一个被注解过的方法 @AroundInvoke，并用 @Interceptors 来注解这个Bean以指定拦截器类的名称。
例如，下面的拦截器检查用户是否在允许调用动作监听器方法之前登录：
public class LoggedInInterceptor {
@AroundInvoke
public Object checkLoggedIn(InvocationContext invocation) throws Exception {
boolean isLoggedIn = Contexts.getSessionContext().get("loggedIn")!=
if (isLoggedIn) {
//the user is already logged in
return invocation.proceed();
//the user is not logged in, fwd to login page
return "login";
要把这个拦截器应用到一个作为动作监听器的会话Bean上，我们必须注解这个会话Bean @Interceptors(LoggedInInterceptor.class)。
这个注解有点丑陋。在EJB 3.0中，Seam通过允许将 @Interceptors 作为元注解使用，而依赖于拦截器框架。
在我们的例子中，将创建一个 @LoggedIn 注解，如下所示：
@Target(TYPE)
@Retention(RUNTIME)
@Interceptors(LoggedInInterceptor.class)
public @interface LoggedIn {}
现在，我们可以简单地用 @LoggedIn 来注解我们的动作监听器Bean以应用拦截器。
@Stateless
@Name("changePasswordAction")
@Interceptors(SeamInterceptor.class)
public class ChangePasswordAction implements ChangePassword {
public String changePassword() { ... }
如果拦截器的顺序很重要（通常是这样），你可以将 @Interceptor 注解添加到你的拦截器类，来指定拦截器的部分顺序
@Interceptor(around={BijectionInterceptor.class,
ValidationInterceptor.class,
ConversationInterceptor.class},
within=RemoveInterceptor.class)
public class LoggedInInterceptor
你甚至可以有一个“客户端”的拦截器，运行关于任何EJB3的内置功能：
@Interceptor(type=CLIENT)
public class LoggedInInterceptor
EJB拦截器是有状态的，有着和它们所拦截组件相同的生命周期。
对哪些不需要维护状态的拦截器而言，Seam通过指定 @Interceptor(stateless=true) 让你获得性能优化。
Seam的很多功能是作为一套内置的Seam拦截器来实现的，包括前面例子里提到的拦截器。
你没有必要通过注解你的组件来明确指定这些拦截器；它们为所有的可注解Seam组件而存在。
你甚至可以在JavaBean组件中使用Seam拦截器，不仅仅只有EJB3 Bean能用它们！
EJB定义拦截器，不仅为了业务方法（用@AroundInvoke），也为了生命周期方法
@PostConstruct，@PreDestroy，@PrePassivate 和 @PostActive。
Seam支持组件和拦截器中所有这些生命周期方法，不仅仅支持EJB3 Bean，也支持JavaBean组件（除了@PreDestroy 对JavaBean组件而言没有意义之外）。
5.3.&管理异常
JSF在异常处理方面的能力有限得令人吃惊。
作为解决这个问题的部分权宜之计，Seam让你定义如何通过注解这个异常类来处理异常的特殊类，或者在XML文件中声明这个异常类。
这个工具是想要和EJB3.0标准的 @ApplicationException 的注解组合在一起，这个注解指定了这个异常是否应该导致一个事务回滚。
5.3.1.&异常和事务
EJB指定了定义良好的规则，用以控制异常是否立即标记当前的事务，以便在这个Bean的业务方法抛出一个异常时回滚：
系统异常 总是导致一个事务回滚，应用程序异常 默认是不导致事务回滚的，但是如果指定了 @ApplicationException(rollback=true)，则会导致事物回滚。
（应用程序异常是任何checked异常，或者任何用 @ApplicationException 注解过的unchecked的异常。系统异常是任何没有用 @ApplicationException 注解过的unchecked异常）。
注意：在标记事务回滚和实际的回滚两者之间有一点不同。
异常规则说，只有被标记过的事务应该回滚，但是在异常抛出之后，事务仍然可以是有效的。
Seam对Seam JavaBean组件也应用EJB 3.0 异常回滚规则。
但是，这些规则仅仅应用于Seam组件层。没有捕捉到的异常传播到Seam组件层之外，或是传播到JSF层之外怎么办？
恩，让一个悬空摇摆的事务处于打开状态是不对的，当异常发生，而你又没有在Seam组件层捕捉到它时，Seam会回滚任何活动的事务。
5.3.2.&激活Seam异常处理
要激活Seam的异常处理，需要确保已经在 web.xml 中声明了主要的Servlet过滤器:
&filter-name&Seam Filter&/filter-name&
&filter-class&org.jboss.seam.servlet.SeamFilter&/filter-class&
&filter-mapping&
&filter-name&Seam Filter&/filter-name&
&url-pattern&*.seam&/url-pattern&
&/filter-mapping&
如果你想激活异常处理器，还需要禁用 web.xml 中Facelets的开发模式，和 components.xml 中的调试模式。
5.3.3.&使用注解处理异常
每当异常传播到Seam组件层之外时，下列异常都会导致一个HTTP 404错误。
抛出异常时，它并不立即回滚当前事务，但是如果这个异常没有被其他的Seam组件捕捉到，当前事务将被回滚。
@HttpError(errorCode=404)
public class ApplicationException extends Exception { ... }
每当异常传播到Seam组件层之外时，这个异常会导致浏览器的重定向。它也同时结束当前的对话，导致当前事务立即回滚。
@Redirect(viewId="/failure.xhtml", end=true)
@ApplicationException(rollback=true)
public class UnrecoverableApplicationException extends RuntimeException { ... }
注意：对于那些在JSF生命周期的渲染阶段发生的异常而言，@Redirect 无效。
你也可以用EL指定 viewId 来重定向。
当异常传播到Seam组件层之外时，这个异常导致一个重定向，并给用户一条消息。它也立即回滚当前事务。
@Redirect(viewId="/error.xhtml", message="Unexpected error")
public class SystemException extends RuntimeException { ... }5.3.4.&用XML处理异常
考虑到不能对我们感兴趣的所有异常类添加注解，Seam也允许我们在 pages.xml 中指定这个功能。
&exception class="javax.persistence.EntityNotFoundException"&
&http-error error-code="404"/&
&/exception&
&exception class="javax.persistence.PersistenceException"&
&end-conversation/&
&redirect view-id="/error.xhtml"&
&message&数据库访问失败 Database access failed&/message&
&/redirect&
&/exception&
&exception&
&end-conversation/&
&redirect view-id="/error.xhtml"&
&message&意外的失败 Unexpected failure&/message&
&/redirect&
&/exception&
最后一个 &exception& 声明没有指定类，它捕捉所有的那些没有通过注解或在 pages.xml 中特别指定的任何异常。
你也可以通过EL指定 view-id 来重定向。
你也可以通过EL访问处理后的异常实例，Seam把它放在对话上下文中，比如访问异常的消息。
throw new AuthorizationException("You are not allowed to do this!");
&exception class="org.jboss.seam.security.AuthorizationException"&
&end-conversation/&
&redirect view-id="/error.xhtml"&
&message severity="WARN"&#{org.jboss.seam.handledException.message}&/message&
&/redirect&
&/exception&
org.jboss.seam.handledException 保存着实际上由异常处理器处理的嵌套异常。
最外层的（包装器）异常也可以访问，如 org.jboss.seam.exception。
5.3.5.&一些常见的异常
如果你正在使用JPA：
&exception class="javax.persistence.EntityNotFoundException"&
&redirect view-id="/error.xhtml"&
&message&Not found&/message&
&/redirect&
&/exception&
&exception class="javax.persistence.OptimisticLockException"&
&end-conversation/&
&redirect view-id="/error.xhtml"&
&message&另一个用户修改了相同的数据，请重试 Another user changed the same data, please try again&/message&
&/redirect&
&/exception&
如果你正在使用Seam应用框架：
&exception class="org.jboss.seam.framework.EntityNotFoundException"&
&redirect view-id="/error.xhtml"&
&message&Not found&/message&
&/redirect&
&/exception&
如果你正在使用Seam安全：
&exception class="org.jboss.seam.security.AuthorizationException"&
&redirect&
&message&You don't have permission to do this&/message&
&/redirect&
&/exception&
&exception class="org.jboss.seam.security.NotLoggedInException"&
&redirect view-id="/login.xhtml"&
&message&Please log in first&/message&
&/redirect&
&/exception&
那么，对于JSF：
&exception class="javax.faces.application.ViewExpiredException"&
&redirect view-id="/error.xhtml"&
&message&您的会话已经超时，请重试 Your session has timed out, please try again&/message&
&/redirect&
&/exception&
如果用户会话过期并且返回到原来的页面，就会抛出 ViewExpiredException 异常。
如果你在一个对话里面，no-conversation-view-id 和 conversation-required 可以让你更细粒度地控制会话超期。
