Seam "two transactions per request" 原理解析

In Seam_reference:
“Seam solves both the transaction isolation problem and the association fetching problem, while
working around the problems with "open session in view". The solution comes in two parts:
• use an extended persistence context that is scoped to the conversation, instead of to the
transaction
• use two transactions per request; the first spans the beginning of the restore view phase (some
transaction managers begin the transaction later at the beginning of the apply request vaues
phase) until the end of the invoke application phase; the second spans the render response
phase”

问题：
1.    为什么需要“use two transactions per request”？这两个transaction的各自作用是什么？ Transaction结
束的时候会把对数据库的操作提交到数据库吗？
Answer：“use two transactions per request”是用来完美解决render response phase阶段的lazy loading问题的，比“open session in view”方案要好。
作用：
第一个Transaction： 主要是用于处理该request中可能要用到的对数据库的处理，如查询，修改，新增，删除操作等
，比较好理解。
第二个Transaction：render response phase阶段主要涉及的是lazy loading，主要是查询操作。之所以查询也要包含在某个事务之中，是因为：
a.    获取jdbc connection：在beginTransaction()的时候，会同时获取一个JDBC connection。 hibernate 对
long-running conversation的处理是session-per-conversation，那么什么是session-per-conversation呢？
session-per-conversation：在一般的web应用中，一个conversation跨越多个request多个transaction的现象很常见。在FlushMode.MANUAL情况下，其处理流程是：
http request  -->  create hibernate session -->   get jdbc connection  and begin transaction -->  process http request -->  transaction commit  and release jdbc connection -->  keep hibernate session

........

a new http request -->  resume hibernate session  -->  get jdbc connection  and begin transaction -->  process http request -->  transaction commit and release jdbc connection -->  keep hibernate session or close (if flushed explictly)
其中transaction commit and release jdbc connection是同时进行的，调用tx.commit()的时候将release jdbc
connection。这时因为链接释放模式有如下三种：ON_CLOSE，AFTER_TRANSACTION，AFTER_STATEMENT。对
JDBCTransactionFactory而言，默认采用AFTER_TRANSACTION

b.    保持数据一致性：一般application的事务隔离级别是Read committed。如果不处在一个事务之中，那么很有
可能查询出来的数据不一致。例：现有A，B两个查询，它们不在事务中，在A查询完，B尚未开始时，数据库中A,B相关
的数据都被其他并发操作更新过了，B再查询，这时就会导致A,B查询出来的数据不一致，一个是更新前的数据，一个是
更新后的数据

Transaction结束的时候不会提交到数据库，而是提交到Hibernate的缓存。只有当调用flush方法的时候才会提交到数
据库（auto-commit为false）