Hibernate本身没有事务的实现
Hibernate 直接使用 JDBC 连接和 JTA 资源,不添加任何附加锁定行为。也就是说你在Hibernate里面使用的事务要么是JDBC的事务,要么是JTA的事务。
Hibernate不锁定内存中的对象
你的应用程序会按照你的数据库事务的隔离级别规定的那样运作,真正对事务的实现和支持也依赖于数据库。
对于并发处理,Hibernate提供了乐观锁和悲观锁来进行并发处理
Hibernate对自动乐观并发控制提供版本管理,针对行级悲观锁定,Hibernate 也提供了辅助的(较小的)API,它使用了 SELECT FOR UPDATE 的 SQL 语法
Hibernate的Session是和事务联系在一起的
可以通过Session去获取事务的接口,从而进行事务的控制。
数据库事务应该尽可能的短
这样能降低数据库中的锁争用。数据库长事务会阻止你的应用程序扩展到高的并发负载。因此,假若在用户思考期间让数据库事务开着,直到整个工作单元完成才关闭这个事务,这绝不是一个好的设计。
这就引出一个问题:一个操作单元,也就是一个事务单元的范围应该是多大?
一个操作一个?一个请求一个?一个应用一个?
反模式:session-per-operation
在单个线程中, 不要因为一次简单的数据库调用,就打开和关闭一次 Session!数据库事务也是如此。也就是说应该禁止自动事务提交(auto-commit)。
session-per-request
最常用的模式是 每个请求一个会话。 在这种模式下,来自客户端的请求被发送到服务器端,即 Hibernate 持久化层运行的地方,一个新的 Hibernate Session 被打开,并且执行这个操作单元中所有的数据库操作。一旦操作完成(同时对客户端的响应也准备就绪),session 被同步,然后关闭。会话和请求之间的关系是一对一的关系。
Hibernate 内置了对“当前 session(current session)” 的管理,用于简化此模式。你要做的一切就是在服务器端要处理请求的时候,开启事务,在响应发送给客户之前结束事务,通常使用Servelt Filter来完成。
非托管环境下
所谓非托管,指的是:应用程序没有托管到J2EE环境中,通常由Hibernate自己来负责管理数据库连接池。应用程序开发人员必须手工设置事务声明,换句话说,就是手工启动,提交,或者回滚数据库事务。
使用JTA
又有两种方式,一种是在Hibernate配置里面修改transaction的factory类,从而在程序里面可以直接使用Hibernate的事务API,也就是程序不用变化。
另外一种方式就是直接通过JNDI去查找UserTransaction,然后直接在程序里面使用JTA的接口来控制事务。
应用程序级别的版本检查
简单点说,就是由应用程序自己实现版本检查来确保对话事务的隔离,从数据访问的角度来说是最低效的,不推荐使用。
扩展周期的session和自动版本化
Hibernate 使用扩展周期的 Session 的方式,或者脱管对象实例的方式来提供自动版本检查。单个 Session 实例和它所关联的所有持久化对象实例都被用于整个对话,这被称为 sessionper-
conversation。
Hibernate 在同步的时候进行对象实例的版本检查,如果检测到并发修改则抛出异常。由开发人员来决定是否需要捕获和处理这个异常(通常的抉择是给用户 提供一个合并更改,或者在无脏数据情况下重新进行业务对话的机会)。
在等待用户交互的时候, Session 断开底层的 JDBC 连接。这种方式以数据库访问的角度来说是最高效的方式。应用程序不需要关心版本检查或脱管对象实例的重新关联,在每个数据库事务中,应用程序也不需要载入读取对象实例。
应用程序级别的版本检查
简单点说,就是由应用程序自己实现版本检查来确保对话事务的隔离,从数据访问的角度来说是最低效的,不推荐使用。
扩展周期的session和自动版本化
Hibernate 使用扩展周期的 Session 的方式,或者脱管对象实例的方式来提供自动版本检查。单个 Session 实例和它所关联的所有持久化对象实例都被用于整个对话,这被称为 sessionper-conversation。
Hibernate 在同步的时候进行对象实例的版本检查,如果检测到并发修改则抛出异常。由开发人员来决定是否需要捕获和处理这个异常(通常的抉择是给用户 提供一个合并更改,或者在无脏数据情况下重新进行业务对话的机会)。
在等待用户交互的时候, Session 断开底层的 JDBC 连接。这种方式以数据库访问的角度来说是最高效的方式。应用程序不需要关心版本检查或脱管对象实例的重新关联,在每个数据库事务中,应用程序也不需要载入读取对象实例。
通常不需要自己去管理锁定策略
Hibernate 总是使用数据库的锁定机制,从不在内存中锁定对象。因而用户并不需要花很多精力去担心锁定策略的问题。通常情况下,只要为 JDBC 连接指定一下隔离级别,然后让数据库去搞定一切就够了。
然而,高级用户有时候希望进行一个排它的悲观锁定,或者在一个新的事务启动的时候,重新进行锁定。
类 LockMode 定义了Hibernate 所需的不同的锁定级别
1:当更新或者插入一行记录的时候,锁定级别自动设置为LockMode.WRITE。
2:当用户显式的使用数据库支持的 SQL 格式 SELECT ... FOR UPDATE 发送 SQL 的时候,锁定级别设置为 LockMode.UPGRADE。
3:当用户显式的使用 Oracle 数据库的 SQL 语句 SELECT ... FOR UPDATE NOWAIT 的时候,锁定级别设置 LockMode.UPGRADE_NOWAIT。
4:当 Hibernate 在“可重复读”或者是“序列化”数据库隔离级别下读取数据的时候,锁定模式自动设置为 LockMode.READ。这种模式也可以通过用户显式指定进行设置。
5:LockMode.NONE 代表无需锁定。在 Transaction 结束时, 所有的对象都切换到该模式上来。与session 相关联的对象通过调用 update() 或者 saveOrUpdate() 脱离该模式。
显示的指定锁定模式
1:调用 Session.load() 的时候指定锁定模式(LockMode)。
2:调用 Session.lock()。
3:调用 Query.setLockMode()。
显示指定锁定模式的说明
1:如果在 UPGRADE 或者 UPGRADE_NOWAIT 锁定模式下调用 Session.load(),并且要读取的对象尚未被session 载入过,那么对象通过 SELECT ... FOR UPDATE 这样的 SQL 语句被载入。如果为一个对象调用 load() 方法时,该对象已经在另一个较少限制的锁定模式下被载入了,那么 Hibernate 就对该对象调用 lock() 方法。
2:如果指定的锁定模式是 READ,UPGRADE 或 UPGRADE_NOWAIT,那么 Session.lock() 就执行版本号检查。(在 UPGRADE 或者 UPGRADE_NOWAIT 锁定模式下,执行 SELECT ... FOR UPDATE这样的SQL语句。)
3:如果数据库不支持用户设置的锁定模式,Hibernate 将使用适当的替代模式(而不是扔出异常)。这一点可以确保应用程序的可移植性。
视频配套PPT,视频地址【 Hibernate4实战-独家视频课程 】