理解seam的conversation

几乎所有对seam进行介绍的文档中都会用大量的篇幅来说明会话(conversation)，因为它是seam的发明，让seam与众不同的一个地方。但是要完全理解和运用conversation并不是容易呀。会话是一种用来存储程序上下文数据的容器，和session类似，只不过它的生存周期和session有很大的差别。

会话分成两类，临时会话和长会话。临时会话会开始于服务器端处理客户端的post请求，结束于下一个页面的生成。也就是说，它存在于 post->redirect->get 这样一个小周期内。典型的例子是facesmessage组件。这是一个会话内的组件。我们在处理post请求时，写的message，在下个页面生成的时候依然有效。比如，用户提交一个注册表单，表单POST提交后，服务器调用注册方法，在方法结束的时候，调用facesmessage设定信息“注册成功了！”。然后服务器发送一个跳转的response让浏览器转向index页面。在index页面里，我们输出facesmessages里的内容，这时，这个message能够成功的拿到。因为那个facesmessage组件跨越了那一次跳转。之后，如果提交index上的表单的话，又会有一个新的临时会话产生，之前的会话里的内容将不再存在。长会话可以存活得更长。如果在一个短会话内，程序中执行了带有@Begin的方法，或者在page.xml 里有配置<begin-conversation/>，那么这个临时会话，就会变成一个长会话。如果服务端在执行方法时遇到标有@End的标注，或者在page.xml里遇到<end-conversation />，当前的长会话，将会结束；否则，它会一直持续下去。

会话与JPA的entityManager的关系。一个entityManager与hibernate的session相当。JPA里定义的 entityManager一级缓存的刷新方式只有两种：Auto和commit。seam发明了第三种方式，Manual。Auto意味着，当执行到 select语句时，entityManger会自动执行一下flush()方法，commit会在事务提交时flush()；而Manual则是由你自己来手动控制flush()。每次开始一个会话的时候，seam都会为你开启一个entityManager，这个entityManger会一直打开，直到conversation结束。这是seam的作者Gavin最骄傲的地方了。能让hibernate的session持续在一个会话之内，可以在会话期内的几次服务器与客户端的几次交往中避免LazyInitializationException，最大程度的发挥hibernate延迟载入的能力。其实Gavin最初要把服务端做成这样有状态的，就是因为他认为与orm协作的最佳方式，就是让服务端有状态。

长会话的结束。默认的情况下，当遇到<end-conversation />或@End时，会话并不会立刻结束，而是会在下个页面生成之后才结束，这是为了避免生成页面时无法取到前一个页面POST时处理的结果。但是有的时候，我们确实需要在POST之后，下个页面生成之前就结束掉。这时需要用@End(beforeRedirect=true),或
<end-conversation before-redirect=”true” />。

会话的维持。我们都知道session是靠一个叫JSESSIONID的cookie或者请里的参数来维持的。类似的会话也是通过这么一个特殊的请求参数来控制的，默认为cid。观查cid的变化，能帮助我们查看conversation的变化。

为什么要发明会话呢？？这得从seam的作者Gavin说起。这个牛人发明了杰出的ORM框架hibernate，但是却发现现在的web开发方式并没有正确的使用它。和
hibernate搭档最多的当属spring了。在结合spring使用hibernate的时候，我们很难把握得好hibernate session的范围，如果太窄，那么在这个范围之外对持久对象的调用很容易产生LazyInitializationException。所以后来 OpenSessionInView的方式很流行。但这还是不能完全解决问题。OpenSessionInView把session的范围扩大到了对一个 http request的处理过程之中，而不能处理跨页面的情况。如果把hibernate session扩大到 http session范围内，这显然会让session太长，引发其它问题。所以Gavin觉得需要一种能够跨越页面，并且又不会像http session那样太长的Scope，于是conversation就诞生了。在开发中，尤其是以提交表单方式为主的企业开发中，常常需要用几个页面来配合完成一个用例，这几个页面内的数据往往耦合性强，需要被放到同一个上下文中，而这个上下文用conversation来做也是很自然的。对于Gmail 这样的应用，conversation没什么意义。

Conversation是个好东西，但是一定要小心的使用。一来它存在着性能问题 ，二来用的太多，不小心控制conversation的开始和结束，就会导致conversation的混乱，那个时候会导致一些奇怪的问题。