Hibernate 3.3：重新设计、模块化 JARS 及重构的缓存系统

Hibernate 3.3 主要的新特性包括：

• 重新设计、模块化 JARs——现在有很多定义良好的 JARs，而不是一个大的 JAR 文件——这使得用户可以轻松了解依赖关系并将其最小化，同时还使得组织可以定制 Hibernate，移除不需要的部分
• 基于 Maven 的构建——现在 Hibernate 使用 Apache Maven 构建系统进行构建
• 修补的缓存 SPI——根据反馈重构了缓存系统以对不同的缓存区域的特性进行精细控制
• JBoss Cache 2.x集成——基于新的缓存 SPI，现在可以轻松集成 JBoss Cache 2.x

Ebersole 还详细说明了新的缓存系统和 JBoss Cache 集成：

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 来说无效是非常重要的，因为这是 最有效的运行集群实体缓存的方式。

讨论的另一个话题就是其他 JPA 实现如何影响 Hibernate：

当我第一次看到 TopLink/OpenJPA 时，我正好在做 Hibernate 中的 BytecodeProvider 支持工作。我真的喜欢在类加载时就使用 JVM 代理来动态处理类，而不是在一个单独的构建步骤中进行。Hibernate 并没有采取这种方式，但是我打算在 Hibernate 4.0 中尝试一下，因为那时 Hibernate 就不再支持 JDK 1.4 了。

最近随着 OSGi 的日渐流行，曾被提及的一个问题就是当在 OSGi 容器中运行 Hibernate 时，

有时会出现问题。Ebersole 说他们现在正在检查动态重新定义SessionFactory 的功能，同时他们也知道了一些类加载的问题。但是Ebersole 注意到hibernate-dev 邮件列表上并没有人讨论这些问题，而且也

只有几个 JIRA 对这些问题进行了探讨，同时他还注意到就他所知，在 Hibernate 开发团队中还没有人解决了这些问题。Ebersole 强烈地表达了他想与社区协作的 愿望，以期解决这些问题以及 Hibernate 中的其他任何问题，他还说如果有人对 OSGi 感兴趣或者对其比较了解并且想提升 Hibernate 与 OSGi 的协作性，或者仅仅提出实现这些兼容性的一些建议，他很愿意听取大家的意见。

当被问到 Hibernate 的未来计划时，Ebersole 说到：

既然 3.3.0 GA 已经发布了，我们会有一段时间来解决 JIRA 中提出的关于 3.3.x 的一些问题。我们已经在制定关于 3.4 和 4.0 的计划。一般而言，我们还没有真正讨论过未来的路线图，但是因为 3.4 上的工作已经开始并且其特性集基本上也已确定，我很 乐意多说一些。我们将精力集中于性能改进和资源利用以及使 Hibernate 运行在集群的故障恢复场景中。另外要说的就是“抓取分析（fetch profiles）”的引入，这样你就可以在元数据中建立命名的抓取策略然后在运行时动态应用 Session 上的那些分析。对于 3.4 来说这些都是大问 题。