J2EE規(guī)范現(xiàn)在作為同時(shí)期企業(yè)項(xiàng)目的標(biāo)準(zhǔn)被廣為接受。但是J2EE規(guī)范的一個(gè)重要部分即EJB持久性由于它的開(kāi)發(fā)模型復(fù)雜并且實(shí)體bean的性能很差而長(zhǎng)期受到批評(píng)。人們相信這樣一個(gè)事實(shí)：假如實(shí)體bean（尤其是容器受控持久性實(shí)體bean，或者CMP）用于應(yīng)用程序中，那么性能將受到影響。事實(shí)并非如此。

　　本文中我不打算解釋EJB的復(fù)雜性。即將推出的EJB 3規(guī)范專門針對(duì)目標(biāo)和開(kāi)發(fā)模型，使得它更輕易；該規(guī)范還提供依靠注入以及在實(shí)體bean容器之外的更輕易的測(cè)試。相反，本文的目標(biāo)在于提供BEA WebLogic Server 8.1和9.0中可用的高級(jí)選項(xiàng)的深度分析，使開(kāi)發(fā)人員改善CMP bean的性能——在很多情況下可極大地改善。該主題很寬泛，不可能在一篇文章中一一涉及；因此，我只重點(diǎn)討論CMP實(shí)體bean的并發(fā)以及長(zhǎng)期緩存策略。我還簡(jiǎn)要說(shuō)明了最新版本BEA WebLogic Server 9.0中的改進(jìn)。

　　并發(fā)策略

　　J2EE開(kāi)發(fā)人員知道EJB容器維護(hù)了一個(gè)實(shí)體bean緩存或者池，通?？稍诓渴鹈枋龇信渲?。令人驚異的是，相當(dāng)多的J2EE開(kāi)發(fā)人員不知道這并不意味著一旦J2EE服務(wù)器從數(shù)據(jù)庫(kù)中加載一個(gè)特定的bean實(shí)例，它就不再去數(shù)據(jù)庫(kù)中尋找該實(shí)例，因?yàn)樵搶?shí)例已經(jīng)保存在緩存池中了。相反，默認(rèn)情況下J2EE服務(wù)器執(zhí)行ejbLoad()在每次事務(wù)的開(kāi)始從數(shù)據(jù)庫(kù)中同步該實(shí)例的狀態(tài)?；旧希珻MP bean每運(yùn)行一次（即使該bean在前一個(gè)事務(wù)中已經(jīng)被加載），服務(wù)器就執(zhí)行一次SQL select語(yǔ)句來(lái)刷新它。只有在一個(gè)事務(wù)中操作多個(gè)實(shí)體bean實(shí)例時(shí)，服務(wù)器才會(huì)緩存它們。

　　顯然，在每次事務(wù)中都重新從數(shù)據(jù)庫(kù)中加載狀態(tài)會(huì)造成很大的性能影響！這個(gè)默認(rèn)行為很輕易理解：假如數(shù)據(jù)庫(kù)被多個(gè)進(jìn)程共享，并且每個(gè)進(jìn)程都可以改變數(shù)據(jù)庫(kù)中持久對(duì)象的狀態(tài)，那么這將是最安全的方法。但是可以通過(guò)告訴J2EE服務(wù)器保留事務(wù)間實(shí)體bean的緩存實(shí)例，從而避免大部分時(shí)間里從數(shù)據(jù)庫(kù)中刷新數(shù)據(jù)來(lái)略微改善這種情況。為了解決這個(gè)問(wèn)題并生成一個(gè)最優(yōu)的解決方案，首先我將討論BEA WebLogic Server中可用的不同的并發(fā)策略。

　　對(duì)于EJB開(kāi)發(fā)人員來(lái)說(shuō)很重要的一點(diǎn)是要知道實(shí)體bean中可用的不同并發(fā)策略。令人驚異的是，有的開(kāi)發(fā)人員甚至不知道并發(fā)選項(xiàng)的存在。那么適用于實(shí)體bean的并發(fā)策略是什么呢？EJB容器是一個(gè)高度多線程的應(yīng)用程序，同時(shí)響應(yīng)來(lái)自多個(gè)客戶端的請(qǐng)求，這些請(qǐng)求通常會(huì)訪問(wèn)同一資源，比如數(shù)據(jù)表中的一行。因此，EJB容器應(yīng)該治理對(duì)實(shí)體bean實(shí)例的并發(fā)訪問(wèn)；更加技術(shù)性地講，并發(fā)策略決定了容器如何以及何時(shí)將實(shí)體bean的每個(gè)實(shí)例與底層數(shù)據(jù)庫(kù)同步。

　　目前WebLogic Server中有四種可用的并發(fā)策略：排他、數(shù)據(jù)庫(kù)、樂(lè)觀和只讀。默認(rèn)情況下，從7.0版本開(kāi)始，WebLogic Server就使用的是數(shù)據(jù)庫(kù)并發(fā)。上面四種策略按性能從低到高依次排列。我將討論每種策略的優(yōu)缺點(diǎn)。

　　排他性并發(fā)

　　排他性并發(fā)意味著容器最多為每個(gè)主要鍵值創(chuàng)建一個(gè)實(shí)體bean實(shí)例（比如，表中的一行映射到容器中的一個(gè)EJB實(shí)例）。對(duì)指定實(shí)例的訪問(wèn)是串行的，并且請(qǐng)求是按照順序逐個(gè)執(zhí)行的。這種策略有一些嚴(yán)重的問(wèn)題。首先，性能由于多個(gè)客戶端對(duì)bean的串行訪問(wèn)受到明顯影響，并且您不能再考慮應(yīng)用程序的伸縮性。其次，EJB的單個(gè)實(shí)例（以及容器持有的關(guān)聯(lián)鎖）對(duì)于一個(gè)JVM（一個(gè)服務(wù)器實(shí)例）來(lái)說(shuō)是本地的，不能在集群中工作。該策略只是用于后向兼容（早期版本的WebLogic Server默認(rèn)使用它），應(yīng)該盡量不用。

　　數(shù)據(jù)庫(kù)并發(fā)

　　數(shù)據(jù)庫(kù)并發(fā)策略是目前WebLogic Server版本中的默認(rèn)并發(fā)策略。它提供了數(shù)據(jù)持久性和性能間的折中考慮。原理很簡(jiǎn)單：WebLogic Server并不自己治理鎖，而是為每個(gè)試圖訪問(wèn)該bean的每個(gè)事務(wù)創(chuàng)建一個(gè)新的bean實(shí)例，并將并發(fā)控制和死鎖檢測(cè)委派給底層數(shù)據(jù)庫(kù)。這就像多個(gè)客戶端對(duì)單個(gè)數(shù)據(jù)庫(kù)進(jìn)行并行數(shù)據(jù)庫(kù)操作；數(shù)據(jù)庫(kù)的隔離水平和鎖定策略將規(guī)定哪些更新、選擇和插入會(huì)進(jìn)行，按照何種順序，以及哪些（假如有的話）會(huì)失敗。直接好處是該策略在集群環(huán)境中的良好適用性——只要集群中的所有節(jié)點(diǎn)共享一個(gè)數(shù)據(jù)庫(kù)，EJB容器就不需要為數(shù)據(jù)同步細(xì)節(jié)而煩惱。

　　該策略明顯比排他性策略更具伸縮性，并且對(duì)于某些應(yīng)用程序效果尤為出眾，但是也無(wú)法擺脫一些嚴(yán)重的性能限制。即使這樣，容器仍保持了一個(gè)實(shí)體bean實(shí)例池，并且這些實(shí)例不包含事務(wù)間的任何中間狀態(tài)。這是實(shí)例池化而不是緩存數(shù)據(jù)。池化無(wú)狀態(tài)實(shí)例的整體思想可能來(lái)自于早期的JVM實(shí)現(xiàn)，那時(shí)對(duì)象創(chuàng)建還是一項(xiàng)很昂貴的操作，并且從性能的角度來(lái)看緩存對(duì)象實(shí)例是有好處的。在現(xiàn)代的JVM中情況并非如此，因?yàn)榇蟛糠智闆r下對(duì)象的創(chuàng)建非?？欤怯捎谠撔袨槭荅JB規(guī)范中描述的，所有供給商都應(yīng)支持它。然而，當(dāng)使用數(shù)據(jù)庫(kù)并發(fā)策略時(shí)，容器從緩存中取出“無(wú)狀態(tài)的”bean實(shí)例，并且必須執(zhí)行一條SQL選擇操作以獲得最新數(shù)據(jù)并填充實(shí)例字段。

　　這種方法可能還不錯(cuò)，因?yàn)槲覀儾挥脫?dān)心“不新鮮的”bean實(shí)例（當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)被從同一集群中的另一個(gè)節(jié)點(diǎn)或者從不同應(yīng)用程序中更新時(shí)），但是性能也同樣受到明顯影響。您總是在每次事務(wù)的開(kāi)始以一個(gè)額外的select操作結(jié)束，即使您只是打算更新bean中的數(shù)據(jù)而對(duì)之前的值并不感愛(ài)好。因此，在主要或僅是執(zhí)行更新或插入操作的應(yīng)用程序中使用實(shí)體bean意義不大——容器可能花大量時(shí)間做不必要的選擇操作，然后再拋棄數(shù)據(jù)。

　　排他性和數(shù)據(jù)庫(kù)并發(fā)策略至少存在一個(gè)共同問(wèn)題：更新丟失的可能性?？梢韵胂髢蓚€(gè)客戶端幾乎同時(shí)更新映射到一個(gè)實(shí)體bean的表中的同一條記錄。假如數(shù)據(jù)庫(kù)中沒(méi)有鎖，先完成的更新操作的結(jié)果會(huì)被其次完成的更新所覆蓋。這是否是可接受的結(jié)果取決于您的業(yè)務(wù)需求。更新丟失通常是不可接受或者不想要的；因此，應(yīng)用程序需要某種機(jī)制來(lái)避免或檢測(cè)更新丟失的情況，并且有機(jī)會(huì)恢復(fù)。當(dāng)應(yīng)用程序部署再多個(gè)節(jié)點(diǎn)上時(shí)使用排他性策略將不能控制更新丟失問(wèn)題。但是如我之前所述，您不應(yīng)再考慮該該策略。

　　數(shù)據(jù)庫(kù)策略通過(guò)將并發(fā)控制委派給數(shù)據(jù)庫(kù)，提供了進(jìn)行讀數(shù)據(jù)操作時(shí)在數(shù)據(jù)庫(kù)中使用排他性鎖的選擇。這是通過(guò)將weblogic-cmp-jar.xml中的use-select-for-update元素設(shè)置為true（默認(rèn)為false）來(lái)實(shí)現(xiàn)的。顧名思義，該動(dòng)作告訴WebLogic Server在加載實(shí)體bean數(shù)據(jù)時(shí)使用“select for update”。生成的數(shù)據(jù)庫(kù)鎖一致存在，直到事務(wù)完成，因此其他事務(wù)不可能在第一個(gè)事務(wù)運(yùn)行期間讀取或更改數(shù)據(jù)。該項(xiàng)技術(shù)也許在“select for update”上組合了“no wait”選項(xiàng)，可能解決更新丟失問(wèn)題以及任何可能的死鎖——只不過(guò)代價(jià)很高。