Java 平臺(tái)持久性機(jī)制的比較

訪問持久性數(shù)據(jù)是所有應(yīng)用都需要考慮的一個(gè)重要方面。Java 語(yǔ)言嚴(yán)格的遵循了持久性數(shù)據(jù)和暫態(tài)性數(shù)據(jù)的分離，將持久性管理留給了應(yīng)用或者分層機(jī)制。SUN使用一種嚴(yán)格的比較機(jī)制測(cè)試和比較了Java平臺(tái)上的各種革新的持久性機(jī)制。

通過選擇，選出了一個(gè)有代表意義的幾個(gè)系統(tǒng)來進(jìn)行評(píng)價(jià)和比較。這些機(jī)制都通過OO7J的基準(zhǔn)測(cè)試進(jìn)行量化分析。

所有的測(cè)試環(huán)境都具有足夠的內(nèi)存，使得測(cè)試數(shù)據(jù)庫(kù)完全可以在內(nèi)存中駐留，排除磁盤訪問等硬件的影響，也是今天主要服務(wù)環(huán)境的通用內(nèi)存容量配置。OO7J的虛擬機(jī)變體設(shè)置性能基線，每一種機(jī)制都和它進(jìn)行比較。OPJ的PJama實(shí)現(xiàn)得到了總體最高分。它只需要最小的源代碼修改，甚至對(duì)OO7J的主體基本不需要，雖然它僅是一個(gè)原型實(shí)現(xiàn)，卻取得了最好的性能。但是它的確需要一個(gè)定制的虛擬機(jī)。

EJB 框架看起來最糟，需要最多的源代碼修改和最壞的性能和可伸縮性。

JOS 和 JBP，雖然因?yàn)樗鼈內(nèi)狈υ隽吭L問從而使得在讀寫數(shù)據(jù)的時(shí)候性能也很糟糕，但是，他也僅需要很少的代碼修改并能在數(shù)據(jù)在內(nèi)存中的情況下全速運(yùn)行。

JDBC 對(duì)源代碼修改也有較大影響，但是性能卻是在JVM和數(shù)據(jù)庫(kù)的邊緣交叉處的大量交互體現(xiàn)的很好。兩個(gè)JDO 的變體則展現(xiàn)出JDO模型對(duì)不同外部數(shù)據(jù)存儲(chǔ)的多能性。特別是JDO-TP 和其事務(wù)對(duì)象模型對(duì)關(guān)系數(shù)據(jù)庫(kù)工作的很好，同時(shí)允許源代碼對(duì)基線保持最小的變更。并且， JDO 的性能也排在前列，一旦數(shù)據(jù)在內(nèi)存中，這是合情合理的，比JDBC 和 EJB而言也是如此。

雖然EJB CMP 的性能要優(yōu)于EJB BMP，其性能也差于JDO-TP很多。EJB性能差的原因還不清楚，也應(yīng)該注意到，一些應(yīng)用服務(wù)企業(yè)有很差的性能，可能是容器實(shí)現(xiàn)的原因。

作為結(jié)論，很顯然，持久性對(duì)應(yīng)用代碼的影響是很寬的，也對(duì)結(jié)果系統(tǒng)的性能影響很大。. 如果在虛擬機(jī)一級(jí)得到支持，OPJ可望提供最有競(jìng)爭(zhēng)力的性能。在另一個(gè)極端，EJB似乎很難達(dá)到可接受的性能水平，除非應(yīng)用對(duì)象模型發(fā)生戲劇性的變化，從而避免在映射到EJB時(shí)產(chǎn)生的細(xì)粒度對(duì)象。雖然這些方法已經(jīng)反映在標(biāo)準(zhǔn)的EJB設(shè)計(jì)模式中了，但是其暗示著在應(yīng)用程序的各個(gè)方面均要附加更多額外的努力。相反，JDO 試圖在對(duì)應(yīng)用設(shè)計(jì)的影響最小的情況下達(dá)到合理的性能，同時(shí)保持對(duì)外部數(shù)據(jù)源的中立。因此，當(dāng)前，JDO 似乎能夠提供面向?qū)ο髴?yīng)用所需的最佳的總體持久性機(jī)制。但是，目前，SUN建議了一個(gè)最新的實(shí)體Bean持久性規(guī)范 [Sun04]，提交給 EJB3.0，它可能更加接近于JDO 模型。

報(bào)告的原文可以在以下地址下載：http://research.sun.com/techrep/2004/smli_tr-2004-136.pdf

同時(shí)，這也是SUN首次公開披露EJB的性能問題。這也解釋了為什么EJB一直得不到很好的廣泛使用的原因，淡然還有它的復(fù)雜性和部署的高成本性（需要昂貴的EJB容器）。作為J2EE規(guī)范中的一個(gè)重要的核心組件，SUN的賭注押在了EJB3.0上面。EJB3.0相關(guān)的持久性機(jī)制（JSR220）吸收了JDO和oracle的TopLink的優(yōu)點(diǎn)，并且可望提供向后兼容性和遷移API。

雖然，EJB從其規(guī)范和目標(biāo)來說看上去很美。但是EJB3.0至少要今年晚些時(shí)候才能出場(chǎng)，目前我們能夠使用什么呢?考察目前市面上的持久性框架，結(jié)合你的應(yīng)用要求，也不難得出選擇。畢竟，應(yīng)用來說，性能并不是第一位的。

對(duì)于持久性框架的選擇，從應(yīng)用和功能上講，主要考慮以下方面：

• 對(duì)O-R mapping框架的使用經(jīng)驗(yàn)。 
• 數(shù)據(jù)源（Data Source），必須支持不同的數(shù)據(jù)源，包括關(guān)系數(shù)據(jù)庫(kù)和JCA體系。
• 最好提供圖形化的映射工具來進(jìn)行對(duì)象和數(shù)據(jù)庫(kù)表之間的映射，自動(dòng)生成XML配置文件。 
• 數(shù)據(jù)庫(kù)支持，可以利用數(shù)據(jù)庫(kù)的優(yōu)勢(shì)，如存儲(chǔ)過程，觸發(fā)器，支持高級(jí)數(shù)據(jù)類型和數(shù)據(jù)庫(kù)安全。 
• 查詢支持，應(yīng)該支持通過Java代碼或者OO查詢機(jī)制，如EJB QL，按例查詢，標(biāo)準(zhǔn)SQL 來編寫自己的查詢。
• 鎖定。必須支持不同應(yīng)用訪問同一數(shù)據(jù)庫(kù)時(shí)候的鎖定機(jī)制。 
• 緩存。提供有效的緩存基址，減少網(wǎng)絡(luò)和查詢的開銷。 并支持不同節(jié)點(diǎn)的集群。
• 支持到EJB 3.0的遷移。

目前，JBOSS已經(jīng)在AS 4.0中提供了EJB3.0的早期實(shí)現(xiàn)。可以參考。http://www.jboss.org/products/ejb3

如果你不怕在Oracle數(shù)據(jù)庫(kù)平臺(tái)上鎖定，你打可使用Toplink，這也是目前性能最好的POJO的持久性框架。Oracle也是EJB3.0的專家組，將來肯定會(huì)提供遷移的手段。 你可以閱讀這篇文章：Preparing for EJB3.0. 地址：http://www.oracle.com/technology/tech/java/newsletter/articles/toplink/preparing_for_ejb_3.html

注：

JOS

JOS，稱為Java對(duì)象序列化，是JDK 1.1 引入的 [Sun99]，它是一種支持幾乎所有對(duì)象到流的編碼和從流解碼的機(jī)制。他不是基于屬性表的編碼，而是基于文本的，對(duì)象序列使用標(biāo)準(zhǔn)的二進(jìn)制編碼格式。JOS 是Java平臺(tái)默認(rèn)的持久性機(jī)制，也被用來作為 JAVA遠(yuǎn)程方法調(diào)用RMI的參數(shù)編組協(xié)議。在最低層次上，JOS 構(gòu)成了對(duì)基礎(chǔ)類型的編碼和解碼的平臺(tái)支持。但是，序列化遇到了類演化的嚴(yán)重問題，這也使得在Java1.4中引入了“JavaBean的長(zhǎng)期持久化”的新系統(tǒng)。

JDBC

JDK 1.1 也引入了Java數(shù)據(jù)庫(kù)連接(JDBC) API [FEB03]作為使用標(biāo)準(zhǔn)的SQL語(yǔ)言在Java和關(guān)系數(shù)據(jù)庫(kù)之間的通信機(jī)制。JDBC為Java 向關(guān)系數(shù)據(jù)庫(kù)提供了一個(gè)強(qiáng)有力的跳板，并且被平臺(tái)上的很多API實(shí)現(xiàn)證明很成功。設(shè)計(jì)者很成功地將Java 編程語(yǔ)言和SQL進(jìn)行了嫁接，而且JDBC 對(duì)直接的數(shù)據(jù)庫(kù)訪問非常容易使用。然而，如果應(yīng)用需要底層數(shù)據(jù)的對(duì)象視圖的時(shí)候，比如，將主鍵轉(zhuǎn)換成相等的對(duì)象間的引用關(guān)系，程序?qū)⒈愕梅浅?fù)雜和容易出錯(cuò)。為了解決這個(gè)問題，有許多系統(tǒng)開發(fā)出來試圖自動(dòng)化這個(gè)流程，這通常稱為是對(duì)象關(guān)系映射（O-R Mapping）。大多數(shù)開發(fā)環(huán)境都提供對(duì)這一機(jī)制的不同程度的支持。 JDBC API 也在發(fā)展，近來支持直接將Java語(yǔ)言中的一個(gè)類映射到SQL的面向?qū)ο髷U(kuò)展中的相等類型。

JDO

在JDBC 開發(fā)的同時(shí)，對(duì)象數(shù)據(jù)庫(kù)管理組 (ODMG)定義了一個(gè)它們的對(duì)象模型到Java語(yǔ)言的綁定[Ced96]，而許多對(duì)象數(shù)據(jù)庫(kù)廠商則提供了這種綁定的實(shí)現(xiàn)。因?yàn)閷?duì)象數(shù)據(jù)庫(kù)并不像關(guān)系數(shù)據(jù)庫(kù)那樣部署普遍，因此反映在這個(gè)綁定上面也是不怎么成功。Java社區(qū)流程（JCP）出現(xiàn)后，這一努力被一個(gè)更廣泛的建議所替代，即Java數(shù)據(jù)對(duì)象 (JDO) [JR03]。JDO 的目標(biāo)是針對(duì)各種各樣的底層數(shù)據(jù)存儲(chǔ)，包括關(guān)系數(shù)據(jù)庫(kù)，并向開發(fā)人員呈現(xiàn)一個(gè)類似于LJS所定義的對(duì)象模型，但附加限制更少。而許多對(duì)象數(shù)據(jù)庫(kù)廠商也支持JDO。

OPJ

綜合這些努力，SUN和 Glasgow 大學(xué)合作，提出了一個(gè)Java平臺(tái)的正交持久化機(jī)制 (OPJ) [JA00]。這一方法以極高的透明性支持變成語(yǔ)言的各個(gè)方面。從本質(zhì)上講，OPJ 添加了對(duì)JVM穩(wěn)定內(nèi)存的支持，也意味著這一對(duì)JVM 實(shí)現(xiàn)的要求根本上限制了其可接受性。