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