Java 平臺持久性機制的比較

訪問持久性數據是所有應用都需要考慮的一個重要方面。Java 語言嚴格的遵循了持久性數據和暫態性數據的分離，將持久性管理留給了應用或者分層機制。SUN使用一種嚴格的比較機制測試和比較了Java平臺上的各種革新的持久性機制。

通過選擇，選出了一個有代表意義的幾個系統來進行評價和比較。這些機制都通過OO7J的基準測試進行量化分析。

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

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

JOS 和 JBP，雖然因為它們缺乏增量訪問從而使得在讀寫數據的時候性能也很糟糕，但是，他也僅需要很少的代碼修改并能在數據在內存中的情況下全速運行。

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

雖然EJB CMP 的性能要優于EJB BMP，其性能也差于JDO-TP很多。EJB性能差的原因還不清楚，也應該注意到，一些應用服務企業有很差的性能，可能是容器實現的原因。

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

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

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

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

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

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

目前，JBOSS已經在AS 4.0中提供了EJB3.0的早期實現?？梢詤⒖?。http://www.jboss.org/products/ejb3

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

注：

JOS

JOS，稱為Java對象序列化，是JDK 1.1 引入的 [Sun99]，它是一種支持幾乎所有對象到流的編碼和從流解碼的機制。他不是基于屬性表的編碼，而是基于文本的，對象序列使用標準的二進制編碼格式。JOS 是Java平臺默認的持久性機制，也被用來作為 JAVA遠程方法調用RMI的參數編組協議。在最低層次上，JOS 構成了對基礎類型的編碼和解碼的平臺支持。但是，序列化遇到了類演化的嚴重問題，這也使得在Java1.4中引入了“JavaBean的長期持久化”的新系統。

JDBC

JDK 1.1 也引入了Java數據庫連接(JDBC) API [FEB03]作為使用標準的SQL語言在Java和關系數據庫之間的通信機制。JDBC為Java 向關系數據庫提供了一個強有力的跳板，并且被平臺上的很多API實現證明很成功。設計者很成功地將Java 編程語言和SQL進行了嫁接，而且JDBC 對直接的數據庫訪問非常容易使用。然而，如果應用需要底層數據的對象視圖的時候，比如，將主鍵轉換成相等的對象間的引用關系，程序將便得非常復雜和容易出錯。為了解決這個問題，有許多系統開發出來試圖自動化這個流程，這通常稱為是對象關系映射（O-R Mapping）。大多數開發環境都提供對這一機制的不同程度的支持。 JDBC API 也在發展，近來支持直接將Java語言中的一個類映射到SQL的面向對象擴展中的相等類型。

JDO

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

OPJ

綜合這些努力，SUN和 Glasgow 大學合作，提出了一個Java平臺的正交持久化機制 (OPJ) [JA00]。這一方法以極高的透明性支持變成語言的各個方面。從本質上講，OPJ 添加了對JVM穩定內存的支持，也意味著這一對JVM 實現的要求根本上限制了其可接受性。