Hibernate 缓存策略
一级缓存:session,hibernate的自主缓存
二级缓存(Ehcache)
Read-only
Nonstrict-read-write
Read-write(关键事务)
Transactional(事务型缓存<Ehcache不支持此模式>)
二级缓存还有JbossCache的,它支持事务型缓存,但是Jboss的资料很难得,还是开源的Ehcache对我的口味,并且他作为hibernate的默认缓存策略,表现实在也很不错的J
Ehcache在Spring+hibernate的应用中是很简单的,只要声明Ehcache的缓存管理器,并且定义ehcache的xml文件就可以了。
Hibernate 锁策略
Hibernate 内部锁机制
LockMode.NONE 无锁机制
LockMode.WRITE hibernate 进行保存和更新时自动使用的锁机制。
LockMode.READ hibernate读取纪录时的机制
悲观锁
整个数据处理过程中,将数据处于锁定
状态。悲观锁的实现,往往依靠数据库提供的锁机制
LockMode.UPGRADE
LockMode.UPGRADE_NOWAIT
实现机制如下:
Criteria.setLockMode
Query.setLockMode
Session.lock
乐观锁
Why 乐观锁?
更加宽松的加锁机制,悲观锁对长事务而言,开销往往无法承受;避免死锁。
实现机制:
Version
Dirty
ALL
主要介绍 Version
官方推荐的乐观锁实现策略,广泛使用,具有经验可借鉴性
实现举例:在每一次进行读取操作时取出版本号,在进行更新时同时刷新版本号,更新时只能更新低版本的数据,从而完成锁策略。Hibernate的Session会在等待用户交互时,Session断开数据库连接。在整个应用事务过程中,Hibernate使用单例Session和单例类来实现。
使用方法:
<class name="mtn.gfkd.spring.model.TUser" table="T_USER" schema="SPRINGDEV" optimistic-lock="version">
<主键>
<version
column="version"
name="version"
type="java.lang.Integer"
/>
同时数据库表中增加字段àversion
总结:在一般性的事务中,大可将锁机制抛开不用,这样不可否认增加了复杂性,你不得不面对不少的版本异常信息,只有在涉及关键业务如进行网上购物的付款等就必须进行加锁管理,当然推荐基于version的乐观锁管理。
Hibernate 数据加载
Session.createQuery.list()
Session.createQuery. iterate()à遍历,sql语句执行为1,1,1 为什么还要选用他?
Session.get/Load
区别何在?
Session缓存/一、二级缓存
QueryCache机制
Hibernate 批量数据处理
主要问题在于批量操作后的缓存问题!
批量删除例子:
Query query=session.createQuery(delete TUser)
Int ret=query.executeUpdate();
通过高效的JDBC接口批量删除数据后,Session中的缓存,二级缓存并没有清除!!
此时的session.load(TUser,1) 还有数据,显然需要手工的处理。
一个小小的规则
One-many配置时,inverse属性的设置总是将many一方设置为主控方(inverse=false)
区分cascade与inverse的区别
Cascadeà级连关系
Inverseà关系维护控制方向
n 没有工具可以限制我们,限制我们的仅仅是我们自己的想象力而已。
以上是我的一个hibernate讲座的ppt所整理,难免有些不清楚,以后有时间慢慢补齐了J
一级缓存:session,hibernate的自主缓存
二级缓存(Ehcache)
Read-only
Nonstrict-read-write
Read-write(关键事务)
Transactional(事务型缓存<Ehcache不支持此模式>)
二级缓存还有JbossCache的,它支持事务型缓存,但是Jboss的资料很难得,还是开源的Ehcache对我的口味,并且他作为hibernate的默认缓存策略,表现实在也很不错的J
Ehcache在Spring+hibernate的应用中是很简单的,只要声明Ehcache的缓存管理器,并且定义ehcache的xml文件就可以了。
Hibernate 锁策略
Hibernate 内部锁机制
LockMode.NONE 无锁机制
LockMode.WRITE hibernate 进行保存和更新时自动使用的锁机制。
LockMode.READ hibernate读取纪录时的机制
悲观锁
整个数据处理过程中,将数据处于锁定
状态。悲观锁的实现,往往依靠数据库提供的锁机制
LockMode.UPGRADE
LockMode.UPGRADE_NOWAIT
实现机制如下:
Criteria.setLockMode
Query.setLockMode
Session.lock
乐观锁
Why 乐观锁?
更加宽松的加锁机制,悲观锁对长事务而言,开销往往无法承受;避免死锁。
实现机制:
Version
Dirty
ALL
主要介绍 Version
官方推荐的乐观锁实现策略,广泛使用,具有经验可借鉴性
实现举例:在每一次进行读取操作时取出版本号,在进行更新时同时刷新版本号,更新时只能更新低版本的数据,从而完成锁策略。Hibernate的Session会在等待用户交互时,Session断开数据库连接。在整个应用事务过程中,Hibernate使用单例Session和单例类来实现。
使用方法:
<class name="mtn.gfkd.spring.model.TUser" table="T_USER" schema="SPRINGDEV" optimistic-lock="version">
<主键>
<version
column="version"
name="version"
type="java.lang.Integer"
/>
同时数据库表中增加字段àversion
总结:在一般性的事务中,大可将锁机制抛开不用,这样不可否认增加了复杂性,你不得不面对不少的版本异常信息,只有在涉及关键业务如进行网上购物的付款等就必须进行加锁管理,当然推荐基于version的乐观锁管理。
Hibernate 数据加载
Session.createQuery.list()
Session.createQuery. iterate()à遍历,sql语句执行为1,1,1 为什么还要选用他?
Session.get/Load
区别何在?
Session缓存/一、二级缓存
QueryCache机制
Hibernate 批量数据处理
主要问题在于批量操作后的缓存问题!
批量删除例子:
Query query=session.createQuery(delete TUser)
Int ret=query.executeUpdate();
通过高效的JDBC接口批量删除数据后,Session中的缓存,二级缓存并没有清除!!
此时的session.load(TUser,1) 还有数据,显然需要手工的处理。
一个小小的规则
One-many配置时,inverse属性的设置总是将many一方设置为主控方(inverse=false)
区分cascade与inverse的区别
Cascadeà级连关系
Inverseà关系维护控制方向
n 没有工具可以限制我们,限制我们的仅仅是我们自己的想象力而已。
以上是我的一个hibernate讲座的ppt所整理,难免有些不清楚,以后有时间慢慢补齐了J