Hibernate 3.3：重新设计、模块化JARS及重构的缓存系统
发布: 2008-8-28 16:52 | 作者: fendou | 来源: 青软培训-踏踏实实育人-勤勤恳恳奉献
作者 ryan slobojan译者 张龙 发布于 2008年8月25日 上午4时38分
hibernate是一个基于java的对象/关系（o/r）映射框架，今天发布了3.3版。infoq采访了项目领导者steve ebersole以了解该发布的一些情况及它向hibernate增加的新特性。
hibernate 3.3主要的新特性包括：
ebersole还详细说明了新的缓存系统和jboss cache集成：
<blockquote id="k:zd29">
spi的主要变化围绕着如何在特定目的下构建缓存区域而展开。基本上hibernate需要缓存区域完成四个不同的目的： 实体数据、集合数据、查询结果及时间戳更新。以前的spi试图以单一方式处理这些不同类型数据；本质上它试图以普遍的方式来对待数据缓存而不管所存储数据 的特性。但是在实践中我们发现很多时候缓存集成器需要考虑到那些不同特性。例如在集群缓存中，让实体和集合数据及查询和时间戳更新区域同时失效或许很有意 义。如果不基于区域名称采取一些手段的话，以前的spi是不可能处理这种混合匹配的。新的spi使这些区别变得清晰明了。例如有一个叫做 “buildentityregion”或者“buildcollectionregion”的方法，那么缓存集成器就可以确定特定区域的数据类型是可以持有并构建一个恰当的配置好的缓存/区域的。
jbosscache 2.x集成现在是直接使用新的spi的唯一的缓存集成（其余的使用了连接新式和旧式spi的桥，现在已不建议使用了）。同样，它充分利用了我上面提到的那 些区别以使得用户可以为不同区域定义不同行为。jbosscache 2.x相对于jbosscache 1.x来说有两个具体的改进有助于hibernate的使用。第一个是增加了“putforexternalread”过程。当使用jbosscache 1.x，我们在从数据库读取数据并将其放到jbosscache区域中，有时会遇到性能问题，甚至还会发生死锁。情况是这样的：当我们尝试将只读数据放到 节点上时，jbosscache需要一个写锁，尽管整体操作的语义需要的是一个读锁。然后该写锁阻塞了其他事务。jbosscache 2.x引入了一个针对该用例而特别设计的方法，集成时就使用了该方法。
从使用hibernate的角度来看 jbosscache 2.x中其他重要的改进就是它使用乐观锁更好地管理集群中无效的节点。最大的改变就是有一个“碑石（tombstone）”来检查无效的实体，这样后面如 果尝试往缓存中的该实体进行写入操作时就会知道无效的版本是什么并且还会执行一个恰当的版本检验。对于hibernate来说无效是非常重要的，因为这是 最有效的运行集群实体缓存的方式。
</blockquote>
讨论的另一个话题就是其他jpa实现如何影响hibernate：
<blockquote id="k:zd35">当我第一次看到toplink/openjpa时，我正好在做hibernate中的bytecodeprovider 支持工作。我真的喜欢在类加载时就使用jvm代理来动态处理类，而不是在一个单独的构建步骤中进行。hibernate并没有采取这种方式，但是我打算在 hibernate 4.0中尝试一下，因为那时hibernate就不再支持jdk 1.4了。 </blockquote>
最近随着osgi的日渐流行，曾被提及的一个问题就是当在osgi容器中运行hibernate时，有时会出现问题。ebersole说他们现在正在检查动态重新定义sessionfactory的功能，同时他们也知道了一些类加载的问题。但是ebersole注意到hibernate-dev邮件列表上并没有人讨论这些问题，而且也只有几个jira 对这些问题进行了探讨，同时他还注意到就他所知，在hibernate开发团队中还没有人解决了这些问题。ebersole强烈地表达了他想与社区协作的 愿望，以期解决这些问题以及hibernate中的其他任何问题，他还说如果有人对osgi感兴趣或者对其比较了解并且想提升hibernate与 osgi的协作性，或者仅仅提出实现这些兼容性的一些建议，他很愿意听取大家的意见。
当被问到hibernate的未来计划时，ebersole说到：
<blockquote id="k:zd40">既然3.3.0 ga已经发布了，我们会有一段时间来解决jira中提出的关于3.3.x的一些问题。
我们已经在制定关于3.4和4.0的计划。一般而言，我们还没有真正讨论过未来的路线图，但是因为3.4上的工作已经开始并且其特性集基本上也已确定，我很 乐意多说一些。我们将精力集中于性能改进和资源利用以及使hibernate运行在集群的故障恢复场景中。另外要说的就是“抓取分析（fetch profiles）”的引入，这样你就可以在元数据中建立命名的抓取策略然后在运行时动态应用session上的那些分析。对于3.4来说这些都是大问 题。</blockquote>
hibernate是一个基于java的对象/关系（o/r）映射框架，今天发布了3.3版。infoq采访了项目领导者steve ebersole以了解该发布的一些情况及它向hibernate增加的新特性。
hibernate 3.3主要的新特性包括：
- <strong id="vsfa">重新设计、模块化jars--现在有很多定义良好的jars，而不是一个大的jar文件--这使得用户可以轻松了解依赖关系并将其最小化，同时还使得组织可以定制hibernate，移除不需要的部分
- <strong id="y158">基于maven的构建--现在hibernate使用apache maven构建系统进行构建
- <strong id="yi_q">修补的缓存spi--根据反馈重构了缓存系统以对不同的缓存区域的特性进行精细控制
- <strong id="fw-60">jboss cache 2.x集成--基于新的缓存spi，现在可以轻松集成jboss cache 2.x
ebersole还详细说明了新的缓存系统和jboss cache集成：
<blockquote id="k:zd29">
spi的主要变化围绕着如何在特定目的下构建缓存区域而展开。基本上hibernate需要缓存区域完成四个不同的目的： 实体数据、集合数据、查询结果及时间戳更新。以前的spi试图以单一方式处理这些不同类型数据；本质上它试图以普遍的方式来对待数据缓存而不管所存储数据 的特性。但是在实践中我们发现很多时候缓存集成器需要考虑到那些不同特性。例如在集群缓存中，让实体和集合数据及查询和时间戳更新区域同时失效或许很有意 义。如果不基于区域名称采取一些手段的话，以前的spi是不可能处理这种混合匹配的。新的spi使这些区别变得清晰明了。例如有一个叫做 “buildentityregion”或者“buildcollectionregion”的方法，那么缓存集成器就可以确定特定区域的数据类型是可以持有并构建一个恰当的配置好的缓存/区域的。
jbosscache 2.x集成现在是直接使用新的spi的唯一的缓存集成（其余的使用了连接新式和旧式spi的桥，现在已不建议使用了）。同样，它充分利用了我上面提到的那 些区别以使得用户可以为不同区域定义不同行为。jbosscache 2.x相对于jbosscache 1.x来说有两个具体的改进有助于hibernate的使用。第一个是增加了“putforexternalread”过程。当使用jbosscache 1.x，我们在从数据库读取数据并将其放到jbosscache区域中，有时会遇到性能问题，甚至还会发生死锁。情况是这样的：当我们尝试将只读数据放到 节点上时，jbosscache需要一个写锁，尽管整体操作的语义需要的是一个读锁。然后该写锁阻塞了其他事务。jbosscache 2.x引入了一个针对该用例而特别设计的方法，集成时就使用了该方法。
从使用hibernate的角度来看 jbosscache 2.x中其他重要的改进就是它使用乐观锁更好地管理集群中无效的节点。最大的改变就是有一个“碑石（tombstone）”来检查无效的实体，这样后面如 果尝试往缓存中的该实体进行写入操作时就会知道无效的版本是什么并且还会执行一个恰当的版本检验。对于hibernate来说无效是非常重要的，因为这是 最有效的运行集群实体缓存的方式。
</blockquote>
讨论的另一个话题就是其他jpa实现如何影响hibernate：
<blockquote id="k:zd35">当我第一次看到toplink/openjpa时，我正好在做hibernate中的bytecodeprovider 支持工作。我真的喜欢在类加载时就使用jvm代理来动态处理类，而不是在一个单独的构建步骤中进行。hibernate并没有采取这种方式，但是我打算在 hibernate 4.0中尝试一下，因为那时hibernate就不再支持jdk 1.4了。 </blockquote>
最近随着osgi的日渐流行，曾被提及的一个问题就是当在osgi容器中运行hibernate时，有时会出现问题。ebersole说他们现在正在检查动态重新定义sessionfactory的功能，同时他们也知道了一些类加载的问题。但是ebersole注意到hibernate-dev邮件列表上并没有人讨论这些问题，而且也只有几个jira 对这些问题进行了探讨，同时他还注意到就他所知，在hibernate开发团队中还没有人解决了这些问题。ebersole强烈地表达了他想与社区协作的 愿望，以期解决这些问题以及hibernate中的其他任何问题，他还说如果有人对osgi感兴趣或者对其比较了解并且想提升hibernate与 osgi的协作性，或者仅仅提出实现这些兼容性的一些建议，他很愿意听取大家的意见。
当被问到hibernate的未来计划时，ebersole说到：
<blockquote id="k:zd40">既然3.3.0 ga已经发布了，我们会有一段时间来解决jira中提出的关于3.3.x的一些问题。
我们已经在制定关于3.4和4.0的计划。一般而言，我们还没有真正讨论过未来的路线图，但是因为3.4上的工作已经开始并且其特性集基本上也已确定，我很 乐意多说一些。我们将精力集中于性能改进和资源利用以及使hibernate运行在集群的故障恢复场景中。另外要说的就是“抓取分析（fetch profiles）”的引入，这样你就可以在元数据中建立命名的抓取策略然后在运行时动态应用session上的那些分析。对于3.4来说这些都是大问 题。</blockquote>
