因为专注,所以专业

我的Java Blog

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  21 随笔 :: 30 文章 :: 6 评论 :: 0 Trackbacks

1. Session和事务范围(transaction scope)
   SessionFactory
对象的创建代价很昂贵,它是线程安全的对象,它为所有的应用程序线程所共享。它只创建一次,通常是在应用程序启动的时候,由一个Configuraion的实例来创建。

Session对象的创建代价比较小,是非线程安全的,对于单个请求,单个会话、单个的 工作单元而言,它只被使用一次,然后就丢弃。只有在需要的时候,一个Session对象 才会获取一个JDBC的Connection(或一个Datasource) 对象,因此假若不使用的时候它不消费任何资源。

此外我们还要考虑数据库事务。数据库事务应该尽可能的短,降低数据库中的锁争用。 数据库长事务会阻止你的应用程序扩展到高的并发负载。因此,假若在用户思考期间让数据库事务开着,直到整个工作单元完成才关闭这个事务,这绝不是一个好的设计。

一个操作单元(Unit of work)的范围是多大?单个的Hibernate Session能跨越多个 数据库事务吗?还是一个Session的作用范围对应一个数据库事务的范围?应该何时打开 Session,何时关闭Session?,你又如何划分数据库事务的边界呢?
1.1 操作单元(Unit of work)

         首先,别用session-per-operation这种反模式了,也就是说,在单个线程中, 不要因为一次简单的数据库调用,就打开和关闭一次Session!数据库事务也是如此。 应用程序中的数据库调用是按照计划好的次序,分组为原子的操作单元。(注意,这也意味着,应用程 序中,在单个的SQL语句发送之后,自动事务提交(auto-commit)模式失效了。这种模式专门为SQL控制台操作设计的。 Hibernate禁止立即自动事务提交模式,或者期望应用服务器禁止立即自动事务提交模式。)数据库事务绝不是可有可无的,任何与数据库之间的通讯都必须在某个事务中进行,不管你是在读还是在写数据。对读数据而言,应该避免auto-commit行为,因为很多小的事务比一个清晰定义的工作单元性能差。后者也更容易维护和扩展。

在多用户的client/server应用程序中,最常用的模式是 每个请求一个会话(session-per-request)。 在这种模式下,来自客户端的请求被发送到服务器端(即Hibernate持久化层运行的地方),一 个新的Hibernate Session被打开,并且执行这个操作单元中所有的数据库操作。 一旦操作完成(同时对客户端的响应也准备就绪),session被同步,然后关闭。你也可以使用单 个数据库事务来处理客户端请求,在你打开Session之后启动事务,在你关闭 Session之前提交事务。会话和请求之间的关系是一对一的关系,这种模式对 于大多数应用程序来说是很棒的。

实现才是真正的挑战。Hibernate内置了对"当前session(current session)" 的管理,用于简化此模式。你要做的一切就是在服务器端要处理请求的时候,开启事务,在响应发送给客户之前结束事务。你可以用任何方式来完成这一操作,通常的方案有ServletFilter,在service方法中进行pointcut的AOP拦截器,或者proxy/interception容器。EJB容器是实现横切诸如EJB session bean上的事务分界,用CMT对事务进行声明等方面的标准手段。假若你决定使用编程式的事务分界,请参考本章后面讲到的Hibernate Transaction API,这对易用性和代码可移植性都有好处。

在任何时间,任何地方,你的应用代码可以通过简单的调用sessionFactory.getCurrentSession()来访问"当前session",用于处理请求。你总是会得到当前数据库事务范围内的Session。在使用本地资源或JTA环境时,必须配置它,请参见第 2.5 节 “上下文相关的(Contextual)Session”

有时,将Session和数据库事务的边界延伸到"展示层被渲染后"会带来便利。有些serlvet应用程序在对请求进行处理后,有个单独的渲染期,这种延伸对这种程序特别有用。假若你实现你自己的拦截器,把事务边界延伸到展示层渲染结束后非常容易。然而,假若你依赖有容器管理事务的EJB,这就不太容易了,因为事务会在EJB方法返回后结束,而那是在任何展示层渲染开始之前。请访问Hibernate网站和论坛,你可以找到Open Session in View这一模式的提示和示例。
1.1 长对话

         

session-per-request模式不仅仅是一个可以用来设计操作单元的有用概念。很多业务处理都需 要一系列完整的与用户之间的交互,而这些用户是指对数据库有交叉访问的用户。在基于web的应用和企业 应用中,跨用户交互的数据库事务是无法接受的。考虑下面的例子:

  • 在界面的第一屏,打开对话框,用户所看到的数据是被一个特定的 Session 和数据 库事务载入(load)的。用户可以随意修改对话框中的数据对象。

  • 5分钟后,用户点击“保存”,期望所做出的修改被持久化;同时他也期望自己是唯一修改这个信息的人,不会出现 修改冲突。

从用户的角度来看,我们把这个操作单元称为长时间运行的对话(conversation),或者(or 应用事务,application transaction)。 在你的应用程序中,可以有很多种方法来实现它。

头一个幼稚的做法是,在用户思考的过程中,保持Session和数据库事务是打开的, 保持数据库锁定,以阻止并发修改,从而保证数据库事务隔离级别和原子操作。这种方式当然是一个反模式, 因为锁争用会导致应用程序无法扩展并发用户的数目。

很明显,我们必须使用多个数据库事务来实现这个对话。在这个例子中,维护业务处理的 事务隔离变成了应用程序层的部分责任。一个对话通常跨越多个数据库事务。如果仅仅只有一 个数据库事务(最后的那个事务)保存更新过的数据,而所有其他事务只是单纯的读取数据(例如在一 个跨越多个请求/响应周期的向导风格的对话框中),那么应用程序事务将保证其原子性。这种方式比听 起来还要容易实现,特别是当你使用了Hibernate的下述特性的时候:

  • 自动版本化 - Hibernate能够自动进行乐观并发控制 ,如果在用户思考 的过程中发生并发修改,Hibernate能够自动检测到。一般我们只在对话结束时才检查。

  • 脱管对象(Detached Objects)- 如果你决定采用前面已经讨论过的 session-per-request模式,所有载入的实例在用户思考的过程 中都处于与Session脱离的状态。Hibernate允许你把与Session脱离的对象重新关联到Session 上,并且对修改进行持久化,这种模式被称为 session-per-request-with-detached-objects。自动版本化被用来隔离并发修改。

  • Extended (or Long) Session - Hibernate 的Session 可以在数据库事务提交之后和底层的JDBC连接断开,当一个新的客户端请求到来的时候,它又重新连接上底层的 JDBC连接。这种模式被称之为session-per-conversation,这种情况可 能会造成不必要的Session和JDBC连接的重新关联。自动版本化被用来隔离并发修改, Session通常不允许自动flush,而是明确flush。

session-per-request-with-detached-objectssession-per-conversation 各有优缺点,我们在本章后面乐观并发 控制那部分再进行讨论。


posted on 2010-05-20 00:04 kevin.zhan 阅读(192) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: