hibernate 缓存 懒加载

原文链接：http://topic.csdn.net/u/20100624/18/5BE2C394-52DC-4C98-BF4B-FC5A6C8BEDDF.html

对hibernate使用的一些个人总结,欢迎讨论!

1.对于orm关联映射问题,最大的困扰就是查询,如果把关系表结构全权交给它去维护,程序员的负担相当大,如果后期出现性能问题需要优化,就连dba也束手无策,所以我一半不采用hibernate去做关联关系映射只做最简单的字段映射,对于复杂关联查询
第一种办法:是封装视图sql语句,最终面向视图对象实现查询;
第二种办法:采用spring的jdbc查询来实现原生sql,效率高,事务好处理(统一由spring管理),批量执行也不错,可能会对项目移植产生不利,但有时候我们在效率和通用性之间不得不出选择,你愿意更倾向哪个,当然一种折中办法

2.hibernate的懒加载问题,懒加载一直是hibernate引以为荣的特性,但是实用性确实不高,甚至大打折扣,因为为了实现懒加载,我们不得不去设置opensessioninview这个东西,这个相信大家都比较熟悉,它不仅破坏了项目结构还会导致系列安全问题带来脏数据问题.
详细解叙:session随着周期变长,一级缓存中的数据越来越大,脏读数据层出不穷,有时候明明更改了数据查出来还是缓存,原因就是hibernate默认查询的所有数据都从一级缓存中取,这就不得不逼着我们再去程序中仔细分析更改查询先后顺序,多写上几句flush(),更新或者清空一级缓存,如果某个用户点击查询网络中断,卡死在某处,此数据库资源将一直被占用,永不释放,数据库资源用不了多久就枯竭,当然你可以再去设置最大超时时间,最大连接数等等继续搞定这个问题,但是你还要面对一个事务问题,它默认会将未加加入事务的session提交策略设置成为FlushMode.NEVER状态,导致你的查询修改产生著的:FlushMode.NEVER错误,引入一个opensessioninview,却又带来那么多新的问题,面对这个令人无语的设计,有没有更好的解决办法?
解决办法:
第一种:配置使用jion策略,告别懒加载,直击瞄准抓取出你所想要的对象,告别懒加载,不要迷恋,事实上它并不能为你带来多高效率,相反为了满足它,你不得不去牺牲更多
第二种:使用hql 的连接查询,此二种方法都可以,而且还可以有效避免n+1查询问题

3.hibernate的2级缓存,hibernate的查询对于不管你将取什么样的字段,取多少字段都会为你单独去创建一个对象来保存,这是多么大的浪费,看上去系统效率提高了,其实你浪费了多少的虚拟机内存,是否还打算加大设置?继续任期发展?不要太迷恋hibernate,更加善用慎用二级缓存,对于一些固定的字典数据,我们可以采用,首次查询加载配置信息时候,int()中使用list(),而后的查询中多使用iterator(),设置超出内存大小采用序列化本地的配置,从物理上读取缓存数据,这都可以大大提升我们的效率

4.数据库连接池的配置,许多人喜欢用hibernate配置数据源,或者用spring来配置,这都是不符合规范的做法,数据源应该交给中间件,交给web服务器去管理,用过weblgic的人应该深有体会,weblgic后台可以实时监控数据源的使用情况,修改调配也变得非常容易,否则,你就得不断关掉应用修改配置,更谈不上监控配置了,生产机上多是将数据源与应用分开,只有开发环境才那么配置,而tomcat就采用jndi的形式去配置,最终在web.xml中设置下,直接从到容器获取数据源