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 实现的要求根本上限制了其可接受性。