重新设计 模块化JARS及重构的缓存系统

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

SPI的主要变化围绕着如何在特定目的下构建缓存区域而展开。基本上Hibernate需要缓存区域完成四个不同的目的： 实体数据、集合数据、查询结果及时间戳新新。以前的SPI试图以单一方式处理这些不同类型数据；本质上它试图以普遍的方式来对待数据缓存而不管所存储数据 的特性。但是在实践中我们发现很多时候缓存集成器需要考虑到那些不同特性。例如在集群缓存中，让实体和集合数据及查询和时间戳新新区域同时失效或许很有意 义。如果不基于区域名称采取一些手段的话，以前的SPI是不可能处理这种混合匹配的。新的SPI使这些区别变得清晰明了。例如有一个叫做 “buildEntityRegion”或者“buildCollectionRegion”的方法，那么缓存集成器就可以确定特定区域的数据类型是可以 持有并构建一个恰当的配置好的缓存/区域的。

JBossCache 2.x集成现在是直接使用新的SPI的唯yi的缓存集成（其余的使用了连接新式和旧式SPI的桥，现在已不建议使用了）。同样，它充分利用了我上面提到的那 些区别以使得用户可以为不同区域定义不同行为。JBossCache 2.x相对于JBossCache 1.x来说有两个具体的改进有助于Hibernate的使用。第一个是增加了“putForExternalRead”过程。当使用JBossCache 1.x，我们在从数据库读取数据并将其放到JBossCache区域中，有时会遇到性能问题，甚至还会发生死锁。情况是这样的：当我们尝试将只读数据放到 节点上时，JBossCache需要一个写锁，尽管整体操作的语义需要的是一个读锁。然后该写锁阻塞了其他事务。JBossCache 2.x引入了一个针对该用例而特别设计的方法，集成时就使用了该方法。
从使用Hibernate的角度来看 JBossCache 2.x中其他重要的改进就是它使用乐观锁很好地管理集群中无效的节点。很大的改变就是有一个“碑石（tombstone）”来检查无效的实体，这样后面如 果尝试往缓存中的该实体进行写入操作时就会知道无效的版本是什么并且还会执行一个恰当的版本检验。对于Hibernate来说无效是非常重要的，因为这是 最有效的运行集群实体缓存的方式。

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

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

评论加载中... 内容： 评论者： 验证码：