一．基本概念?
PO是持久化對象，它只是對物理數據實體的一種對象表示。?
VO是值對象，準確地講，它是業務對象。?
FormBean只是HTML表單的封裝，起到在控制層弱化的request中存儲數據的作用，將request的get方法轉?
變為對象的存取值。?
二．緩存策略比較?
Jive?
1．Jive的緩存策略的過程描述：?
(1)條件查詢的時候，Jive用?select?id?from?table_name?where?….?（只選擇ID字段）這樣的SQL語句查詢數據庫，來獲得一個ID列表。?
(2)?Jive根據ID列表中的每個ID，首先查看緩存中是否存在對應ID的數據對象：如果存在，那么直接取出，加入到?結果列表中；如果不存在，那么通過一條select?*?from?table_name?where?id?=?{ID?value}?這樣的SQL查詢數據庫，取出對應的數據對象，放入到結果列表，并把這個數據對象按照ID放入到緩存中。?
(3)?ID查詢的時候，Jive執行類似第(2)步的過程，先從緩存中查找該ID，查不到，再查詢數據庫，然后把結果放入到緩存。?
(4)?刪除、更新、增加數據的時候，同時更新緩存。?
2．Jive緩存策略的優點：?
(1)?ID查詢的時候，如果該ID已經存在于緩存中，那么可以直接取出。節省了一條數據庫查詢。?
(2)?當多次條件查詢的結果集相交的情況下，交集里面的數據對象不用重復從數據庫整個獲取，直接從緩存中獲取即可。比如，第一次查詢的ID列表為{1,?2}，然后根據ID列表的ID從數據庫中一個一個取出數據對象，結果集為{a(id?=?1),?b(id?=?2)}。下一次查詢的ID列表為{2,?3}，由于ID?=?2的數據對象已經存在于緩存中，那么只要從數據庫中取出ID?=?3的數據對象即可。?
3．Jive緩存策略的缺點：?
(1)?在根據條件查找數據對象列表的過程中，DAO的第(1)步用來獲得ID列表的那一次數據庫查詢，是必不可少的。?
(2)?如果第(1)步返回的ID列表中有n個ID，在最壞的命中率（緩存中一個對應ID都沒有）情況下，Jive還要再查詢n次數據庫。最壞情況下，共需要n?+?1數據庫查詢。?
Hibernate?
Hibernate用Session類包裝了數據庫連接從打開到關閉的過程。Session內部維護一個數據對象集合，包括了本Session內選取的、操作的數據對象。這稱為Session內部緩存，是Hibernate的第一級最快緩存，屬于Hibernate的既定行為，不需要進行配置。?
Session的生命期很短，存在于Session內部的第一級最快緩存的生命期當然也很短，命中率自然也很低。當然，這個Session內部緩存的主要作用是保持Session內部數據狀態同步。如果需要跨Session的命中率較高的全局緩存，那么必須對Hibernate進行二級緩存配置。一般來說，同樣數據類型（Class）的數據對象，共用一個二級緩存（或其中的同一塊）。?
1．Hibernate二級緩存策略的過程描述：?
(1)條件查詢的時候，總是發出一條select?*?from?table_name?where?….?（選擇所有字段）這樣的SQL語句查詢數據庫，一次獲得所有的數據對象。?
(2)?把獲得的所有數據對象根據ID放入到第二級緩存中。?
(3)?當Hibernate根據ID訪問數據對象的時候，首先從Session一級緩存中查；查不到，如果配置了二級緩存，那么從二級緩存中查；查不到，再查詢數據庫，把結果按照ID放入到緩存。?
(4)?刪除、更新、增加數據的時候，同時更新緩存。?
2．Hibernate二級緩存策略的優點：?
(1)?具有Jive緩存策略同樣的第(1)條優點：ID查詢的時候，如果該ID已經存在于緩存中，那么可以直接取出。節省了一條數據庫查詢。?
(2)?不具有Jive緩存策略的第(2)條缺點，即hibernate不會有最壞情況下的?n?+?1次數據庫查詢。?
3．Hibernate二級緩存策略的缺點：?
(1)?同Jive緩存策略的第(1)條缺點一樣，條件查詢的時候，第(1)步的數據庫查詢語句是不可少的。而且Hibernate選擇所有的字段，比只選擇ID字段花費的時間和空間都多。?
(2)?不具備Jive緩存策略的第(2)條優點。條件查詢的時候，必須把數據庫對象從數據庫中整個取出，即使該數據庫的ID已經存在于緩存中。?
Hibernate的Query緩存策略?
可以看到，Jive緩存和Hibernate的二級緩存策略，都只是針對于ID查詢的緩存策略，對于條件查詢則毫無作用。（盡管Jive緩存的第(2)個優點，能夠避免重復從數據庫獲取同一個ID對應的數據對象，但select?id?from?…這條數據庫查詢是每次條件查詢都必不可少的）。?
為此，Hibernate提供了針對條件查詢的Query緩存。?
1．Hibernate的Query緩存策略的過程描述：?
(1)?條件查詢的請求一般都包括如下信息：SQL,?SQL需要的參數，記錄范圍（起始位置rowStart，最大記錄個數maxRows)，等。?
(2)?Hibernate首先根據這些信息組成一個Query?Key，根據這個Query?Key到Query緩存中查找對應的結果列表。如果存在，那么返回這個結果列表；如果不存在，查詢數據庫，獲取結果列表，把整個結果列表根據Query?Key放入到Query緩存中。?
(3)?Query?Key中的SQL涉及到一些表名，如果這些表的任何數據發生修改、刪除、增加等操作，這些相關的Query?Key都要從緩存中清空。?
2．Hibernate的Query緩存策略的優點?
(1)?條件查詢的時候，如果Query?Key已經存在于緩存，那么不需要再查詢數據庫。命中的情況下，一次數據庫查詢也不需要。?
3．Hibernate的Query緩存策略的缺點?
(1)?條件查詢涉及到的表中，如果有任何一條記錄增加、刪除、或改變，那么緩存中所有和該表相關的Query?Key都會失效。?
比如，有這樣幾組Query?Key，它們的SQL里面都包括table1。?
SQL?=?select?*?from?table1?where?c1?=???….,?parameter?=?1,?rowStart?=?11,?maxRows?=?20.?
SQL?=?select?*?from?table1?where?c1?=???….,?parameter?=?1,?rowStart?=?21,?maxRows?=?20.?
SQL?=?select?*?from?table1?where?c1?=???…..,?parameter?=?2,?rowStart?=?11,?maxRows?=?20.?
SQL?=?select?*?from?table1?where?c1?=???…..,?parameter?=?2,?rowStart?=?11,?maxRows?=?20.?
SQL?=?select?*?from?table1?where?c2?=???….,?parameter?=?‘abc’,?rowStart?=?11,?maxRows?=?20.?
當table1的任何數據對象（任何字段）改變、增加、刪除的時候，這些Query?Key對應的結果集都不能保證沒有發生變化。很難做到根據數據對象的改動精確判斷哪些Query?Key對應的結果集受到影響。最簡單的實現方法，就是清空所有SQL包含table1的Query?Key。?
(2)?Query緩存中，Query?Key對應的是數據對象列表，假如不同的Query?Key對應的數據對象列表有交集，那么，交集部分的數據對象就是重復存儲的。?
比如，Query?Key?1對應的數據對象列表為{a(id?=?1),?b(id?=?2)}，Query?Key?2對應的數據對象列表為{a(id?=?1),?c(id?=?3)}，這個a就在兩個List同時存在了兩份。?
4．二級緩存和Query緩存同步的困惑?
假如，Query緩存中，一個Query?Key對應的結果列表為{a?(id?=?1)?,?b?(id?=?2),?c?(id?=?3)};?二級緩存里面有也id?=?1對應的數據對象a。?
這兩個數據對象a之間是什么關系？能夠保持狀態同步嗎？我閱讀Hibernate的相關源碼，沒有發現兩個緩存之間的這種同步關系。或者兩者之間毫無關系。就像我上面所說的，只要表數據發生變化，相關的Query?Key都要被清空。所以不用考慮同步問題？
posted on 2007-01-05 09:58
matthew 閱讀(272)
評論(0) 編輯 收藏 所屬分類:
JavaEE