1、在一对多的关联关系中,为保证DML的操作性能和灵活性,其独立实体方与函数依赖实体方的cascade都设置为none,而独立实体方的inverse=true,实体ID的生成策略是影响DML操作性能的一大因素,大多数情况下,native的性能比总是高于assigned,然而实体ID的生成策略更多的时候是取决于需求和业务设计
2、对实体的修改和删除而言应该针对独立实体和函数依赖实体分别执行,而不应该使用级联API模式,因为级联API模式将可能导致更多的IO操作使其降低性能和操作弹性
3、实体的修改通常是先检索,再修改托管实体属性,最后再对托管实体(session关闭之后,与session失去关联的实体)进行修改
4、实体的删除通常也是先检索,再删除该实体即可

5、在多对多的关联关系中,为保证DML的操作性能和灵活性,将映射实体双方的cascade=none,而inverse=false,实体ID的生成策略是影响DML操作性能的一大因素,大多数情况下,native的性能比总是高于assigned,然而实体ID的生成策略更多的时候是取决于需求和业务设计
6、对实体的修改和删除而言应该针对双方实体分别执行,而不应该使用级联API模式,因为多对多的关联映射中无所谓主从实体,使用级联级联API模式将可能导致更多的IO操作使其降低性能和操作弹性
7、实体的修改通常是先检索,再修改托管实体属性,最后再对托管实体(session关闭之后,与session失去关联的实体)进行修改,如果程序中组合了另一方实体则此操作会自动关联修改中间表外键
8、实体的删除通常也是先检索,再删除该实体,此操作不聚合API模式即可自动删除中间表中关联外键;但是因为session中delete执行流程的原因,在实体ID生成策略为assigned时导致删除实体之前执行更多的IO检查操作,于是某些时候出现操作性能上的考虑直接使用瞬态实体操作模式进行删除来避免Hibernate执行更多的select检查

9、添加主键时必须注意ID生成策略,如果ID生成策略为native则保持实体ID值为null,如果ID生成策略为assigned则必须在保存之前指定实体的ID值(不能为null)
10、删除实体时如果实体ID生成策略为native则将直接执行delete操作,如果ID生成策略是assigned则先检查缓存再检查数据库,在记录存在的情况下执行delete操作
11、修改操作一般是先查询得到该实体,然后再删除该实体
12、如果使用ThreadLocalSessionContext来完成查询操作,是否需要事务上下文的支持

13、Hibernate的缓存机制分为一级缓存、二级缓存和查询缓存,其中一级缓存是Hibernate自带的,且是固有不可撤销的,Hibernate提供了对二级缓存支持的接口
14、查询缓存是二级缓存的一部分,它的存在需要二级缓存的支
  持
15、一级缓存是线程安全的,二级缓存是线程不安全的,它需要使用Hibernate的事务策略来管理缓存中的数据
16、EHCache可以与Hibernate无缝集成,该缓存工具提供声明式配置和编程模式两种,我们常用的是声明式配置模式

17、Hibernate中为考虑性能和操作效率起见,大多数情况使用SQLQuery接口代替通用Query接口执行原生SQL查询
18、增删改等DML操作一般使用Session来完成,执行新增操作一般是调用Session中的save方法,这个方法便于返回数据库生成的主键,
     在批  量执行新增和修改时应该在一级缓存限额内实时刷冲数据到磁盘并清空一级缓存;执行批量新增还应该临时关闭二级缓存,避免数         据从一级缓存写入二级缓存中
19、如果通过实体的getter方法获取多个关联实体则应该配置batch-size属性,使用批量装载模式来避免过多的SQL查询引起的低效IO操作
20、为了使SQL与工程项目解藕,我们通常将SQL放在hbm映射配置文件中,编程人员应该养成良好的这种习惯和作风

21、Hibernate有两种锁机制:悲观锁和乐观锁,悲观锁的实现依赖于数据库本身,乐观锁依赖于应用系统施加的版本控制;其中Hibernate推荐使用乐观锁版本隔离并发事务
22、Hibernate中可以在hibernate.cfg.xml中配置连接池,连接池的作用和C3P0实现的连接池各项参数请参考JavaWeb阶段的讲解