HIBERNATE的SESSION和事务

以往开发模式总是针对SESSION-PER-REQUEST来进行,虽然有的时候很棒,但是对于一个相对长业务会话中,存在着多个操作的原子会话,操作期间有用户的考虑时间(跨页面),如果采用SESSION持久化上下文的话,可以在一个业务下保存这个SESSION,在提交方式上设置手动提交,这样就可以在一个SESSION中应用多个事务了,而且不用每次事务结束都同步数据库,只有在原子操作完成的情况才手动同步,但是有两个问题不理解:
1.
用户期间有思考时间,如果这个时候一直持有SESSION的实例,那么JDBC连接应该也是一直连接着,长时间的连接会影响并发访问的速度.但是每次事务结束释放了连接,又是频繁的连接释放.这个地方应该如何来理解?
HIBERNATE中的SESSION实例的创建是否就已经开启了JDBC连接,是否可以在需要的时候才开启连接,而不是实例化SESSION的时候就创建好了JDBC连接,如何设置?
2.我们保留持久化上下文的一个目的是解决懒加载问题,也就是让我们需要应用的实体在受管的环境下,是否实体在受管环境下的话,表示他们与数据库的连接也必须打开,如果关闭的话,就不存在受管的情况了.实际和上面的问题差不多:SESSION实例创建后是否JDBC连接就已经开启?
[该贴被yongbuyanbai于2008-11-16 10:25修改过]

BANQ帮忙解答下啊?希望得到高人详细指点关于这个方面

>SESSION实例创建后是否JDBC连接就已经开启
据我现在了解是这样的，Hibernate没什么神秘 就是JDBC+缓存。就象我在Jivejdon3中使用JDBC+缓存一样，Hibernate重要是保持cache in process 和数据库同步，这个可能比较慢。

在JiveJdon3中，懒加载我是通过service外部来实现，这样数据库连接即用即关。session打开时间越长，危险越大，Hibernate官方说明书中也提到这事情，最怕是Session打开时抛Exception，那一层套一层的逃离，是很可怕的，这是反对象生命周期，因为平时我们编程思维是正生命周期，顺序的，一般不会考虑出错后的exception反生命周期。

在这方面 EJB就比较强些，专门实体容器EntityManager来管理上下文，和Sessionbean业务层前段无关。这可能也是迫使Kavin走上EJB以及SEAM一个原因。

道理就这么简单，谁如果有更优雅的坚决方案，那些讲优雅的人冒出来提出比EntityManager强的方案啊，我也愿意拓展思路，洗耳恭听。

关于session什么时候断开jdbc的连接什么时候连着是这样的：
1.执行beginTransaction（）时候连接jdbc connection
2.事务commit时候断开jdbc connection
关于长业务绘画实现一般有2种策略(我只知道)
1.利用托管对象
2.将session的context定义为managed，并实现拦截器自定义绑定策略