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階段的講解