将Spring、Hibernate与WAS一起使用（3）

使用 Hibernate

Hibernate 是 POJO 的开放源代码持久性框架，它通过 XML 配置文件提供 POJO 到关系数据库表的与对象相关的映射。Hibernate 框架是应用程序调用的、用于数据持久性的数据访问抽象层。此外，Hibernate 还提供了从 Java 类到数据库表（以及从 Java 数据类型到 SQL 数据类型）的映射以及数据查询和检索功能。Hibernate 生成必需的 SQL 调用，还负责结果集处理和对象转换。

Hibernate（如 OpenJPA）实现 Java Persistence API (JPA) 规范，它是 Java EE 5 的必要部分。（有关如何使用 Hibernate 的 developerWorks 文章，请参见参考资料。）

使用场景

以下场景描述了有关如何将 Hibernate 与 WebSphere Application Server 和 WebSphere 堆栈产品结合使用的一些可能场景。这些仅是示例场景，不应认为是推荐的场景。

使用 WebSphere Application Server 数据源

为使 Hibernate 从 WebSphere Application Server 获取数据库连接，必须使用 Java EE（以前称为 J2EE）规范中强制规定的资源引用。这可以确保 WebSphere Application Server 能够为连接池、事务语义和隔离级别提供正确的行为。通过设置 hibernate.connection.datasource 属性（在 Hibernate 配置文件中进行了定义）将 Hibernate 配置为从 WebSphere Application Server 检索数据源，以引用在模块的部署描述符中定义的资源引用（例如 java:comp/env/jdbc/myDSRef）。例如：

<property name="hibernate.connection.datasource">

    java:/comp/env/jdbc/myDSRef

</property>

Web 应用程序的 Java EE 资源引用在 WAR 文件级别定义，这意味着容器中的所有 Servlet 和 Java 类均共享资源引用。在 EJB 模块内部，资源引用在各个 EJB 组件上定义。这意味着，如果许多 EJB 组件都使用相同的 Hibernate 配置，则每个 EJB 必须在每个 EJB 组件上定义相同的引用名称。这会导致复杂的情况，稍后我们将进一步讨论。

配置了数据源之后，确保 Hibernate 正常工作的下一个步骤是正确配置事务支持。

事务策略配置

为了正确地使用事务，Hibernate 需要两个重要部分的配置。第一个部分是 hibernate.transaction.factory_class，它定义事务控制，第二个部分是 hibernate.transaction.manager_lookup_class，它定义注册事务同步的机制，这样，当持久性管理器需要与数据库同步更改时会在事务端得到通知。对于事务控制，同时支持容器管理的配置和 Bean 管理的配置。将 Hibernate 和 WebSphere Application Server 结合使用时，必须在 Hibernate.cfg.xml 中设置以下属性：

对于容器管理的事务：

<property name="hibernate.transaction.factory_class">

    org.hibernate.transaction.CMTTransactionFactory

</property>

<property name="hibernate.transaction.manager_lookup_class">

    org.hibernate.transaction.WebSphereExtendedJTATransactionLookup

</property>

 

对于 Bean 管理的事务：

<property name="hibernate.transaction.factory_class">

    org.hibernate.transaction.JTATransactionFactory

</property>

<property name="hibernate.transaction.manager_lookup_class">

    org.hibernate.transaction.WebSphereExtendedJTATransactionLookup

</property>

<property name="jta.UserTransaction">

    java:comp/UserTransaction

</property >

 

jta.UserTransaction 属性将工厂类配置为从 WebSphere 容器获取 UserTransaction 对象实例的实例。

WebSphere Application Server V6.x 和更高版本在 WebSphere 平台上支持 hibernate.transaction.manager_lookup_class 属性，WebSphere Business Integration Server Foundation V5.1 和更高版本也支持此属性。此属性将 Hibernate 配置为使用在 WebSphere Business Integration Server Foundation V5.1 和 WebSphere Application Server V6.0 中引入的 ExtendedJTATransaction 接口，WebSphere ExtendedJTATransaction 接口建立了一个模式，并通过 JTA 1.1 规范在 Java EE 5 中正式确立。

不支持的事务配置

Hibernate 文档描述了用于在 WebSphere Application Server 版本 4 和 5 产品上运行的事务策略配置，但是这些配置使用内部 WebSphere 接口，在那些早期版本上不受支持。上面描述了仅受支持的 Hibernate 事务配置，如前面所述，这意味着只能在 WebSphere Business Integration Server Foundation V5.1 和 WebSphere Application Server 

Version 6.x 以及更高版本上使用 Hibernate。

WebSphere Application Server 环境中 Hibernate 的使用模式

当结合使用 Hibernate 和 WebSphere Application Server 时，Hibernate 的“按请求会话”和“长对话”模式均可使用。客户必须选择适用于其应用程序的模式，不过我们主张使用“按请求会话”模式，因为它可以提供更好的扩展性。

多个隔离级别

可共享的连接通过让多个资源用户能够共享现有的连接，改进了在 WebSphere Application Server 中的性能。不过，如果可共享的连接和多个隔离级别都是必需的，则为每个连接配置定义单独的资源引用和 Hibernate 会话工厂。不能够更改共享连接的隔离级别。因此，也不可能使用 hibernate.connection.isolation 属性在共享连接上设置隔离级别。有关连接共享的策略和约束的详细信息，请参见 在 WebSphere Application Server V5 中共享连接。（尽管本文通常适合于在 WebSphere Application Server V5 上使用的所有共享连接，但是连接共享建议仍适用于在 V6.x 上运行的 Hibernate。）

Web 应用程序

可以在 HttpSession 对象中使用和存储 Hibernate 的“长对话”会话；不过，Hibernate 会话持有活动实例，由于可能需要将会话序列化或将其复制到其他集群成员，因此将其存储在 HttpSession 中不是可扩展模式。最好使用 HttpSession 来存储断开连接的对象（只要它们非常小，即 10KB 到 50KB），并且在需要更新时，重新将它们与新的 Hibernate 会话关联。这是因为 HttpSession 最适用于书签，而不适用于缓存。在 Improving HttpSession Performance with Smart Serialization 中讨论了如何使 HttpSession 的内存使用率降至最低。不是将 HttpSession 用作缓存，而是考虑使用 ObjectGrid 或 DistributedObjectCache 之类的 WebSphere 数据缓存技术，这在下一部分进行介绍。

有关高性能、可扩展应用程序的最佳实践，强烈建议您阅读 Performance Analysis for Java Websites 一书。

集成二级缓存

Hibernate 会话表示工作单元的范围。在 Hibernate 会话的生命周期中，Session 接口管理持久性。通常，它通过保持对单一线程有效的一级缓存实例并维护它负责的映射实体类实例的识别或状态做到这一点。在完成工作单元（会话）时释放缓存。还可以将二级缓存配置为在 SessionFactory 的所有会话之间共享（包括在集群之间共享）。请注意，在 Hibernate 中进行缓存会导致一些需要解决的问题。第一，对于数据库的外部更改或跨集群更改，无法确保缓存的一致性（除非使用识别集群的缓存）。第二，其他层（如数据库）可能已经缓存，从而使 Hibernate 缓存的值降至最低。在进行应用程序设计时，必须认真考虑这些问题，但是这些问题超出了本文的讨论范围。

Hibernate 附带了几个预配置的缓存。在 Hibernate Cache 文档页中可以找到关于这些缓存的信息。对于只读数据，一个内存缓存可能就足够了。不过，当聚集应用程序并需要集群识别缓存时，本地只读缓存是不够的。如果需要分布式缓存，我们建议使用 WebSphere 提供的分布式缓存实现之一。可以将它们用作 Hibernate 的二级缓存：

DistributedMap/DistributedObjectCache 接口提供支持 WebSphere v6.x 产品系列的分布式缓存。有关详细信息，请参见 Using the DistributedMap and DistributedObjectCache interfaces for the dynamic cache。

作为 WebSphere Extended Deployment 产品一部分的 ObjectGrid 提供可扩展的对象缓存支持。有关详细信息，请参见 ObjectGrid。

在 WebSphere Enterprise Service Bus 和 WebSphere Process Server 中使用 Hibernate

WebSphere Process Server 和 WebSphere Enterprise Service Bus (ESB) 将 

Service Component Architecture (SCA) 和 Service Data Objects (SDO) 用作 SOA 的装配和编程模式。（请参见参考资料，了解关于 SCA 和 SDO 的更多信息。）SCA 组件不是 Java EE 组件，因此它们没有资源引用，但是改为依靠服务和适配器来连接系统。在构建 Java SCA 组件时，不能使用资源引用；因此，SCA 组件不能直接使用 Hibernate。

在这种情况下，应将 Hibernate 持久性隐藏在某种 Facade 后面。有两个备选方案：

创建本地 EJB 会话 Facade 以包装 Hibernate 持久性。会话 Facade 提供适配器逻辑，以便将 Hibernate 实体 POJO 映射到服务数据对象并返回。然后集成开发人员可以使用 EJB 导入调用会话 Facade，并以紧密耦合方式使用对应的服务质量 (QoS) 调用它。

创建 EJB Web 服务会话 Facade 以包装 Hibernate 持久性。然后集成开发人员可以使用 Web 服务导入调用持久性的 Web 服务。这不需要构建 POJO 到 SDO 的转换程序，由于目前 SCA 对数据类型只使用 SDO。图 1 说明了使用两个模式的业务流程，但该流程的详细信息不在本文的讨论范围之内。

· 

图 1. 示例业务流程

WebSphere Application Server V6.1 上的 Hibernate JPA API

Hibernate 的 JPA 支持提供 JPA 标准持久性，并且是专有 Hibernate API 的较好备选方案。Hibernate 的 JPA 实现需要基于 Java SE 5 的运行时，因此，它仅在 WebSphere Application Server V6.1 或更高版本上运行。在发布时，Hibernate 的 JPA 支持不能在 WebSphere System z 和 iSeries 平台上运行。Hibernate 文档描述了如何使用 Hibernate 的 JPA 实现包装和部署应用程序。

不可交互操作的／不可移植的功能

JPA 规范中的 3.2.4.2 部分描述了可能导致互操作性和潜在的可移植性问题的情况。这与结合使用延迟加载（即 @Basic(fetch=LAZY)）和分离对象有关。将分离对象合并回会话时，JPA 将检查该对象，并使用任何更改值来更新数据存储。不过，数据对象是简单的 POJO。在分离时，如果部分 POJO 状态没有加载，则在合并回去时可能显示为已更改。要使它正常工作，供应商必须实现特定于其运行时的序列化技术。这不是互操作的，语义也不能移植。

 

产品和客户技术支持

用户合理关注的领域是对使用开放源代码的项目的支持，以及使用开放源代码对供应商支持其许可产品的影响。IBM 了解某些客户可能希望将非 IBM 的框架和 IBM WebSphere Application Server 结合使用，并且在为客户提供一些信息，以促进他们为 IBM WebSphere Application Server 创建最可靠的操作环境。IBM 考虑了客户安装的开放源代码和应用程序框架，它们或者绑定为应用程序的一部分，或者作为共享库成为应用程序代码的一部分。在使用开放源代码项目时通过谨慎地利用此信息，客户可以满怀信心地使用 IBM 产品，并继续访问 IBM 产品和技术支持。如果在将这些框架与 WebSphere 产品结合使用时遇到问题，IBM 将尽力确保 WebSphere 产品不出现问题。

如果客户认真研究了本文中的建议，并理解以下几个关键点，则预期可以安全地在 IBM 产品上使用 Spring 和 Hibernate 之类的框架：

客户必须确保按 WebSphere Application Server 允许的方式使用这些框架。具体说来，这意味着客户在使用内部产品接口时，不应使用框架——遗憾的是，许多开放源代码框架在未经认真配置的情况下就这样使用了。客户应避免在 WebSphere 上明确记录应避免的场景。

对于开放源代码框架，客户应该确保理解并能够访问他们与 WebSphere Application Server 一起使用的框架的匹配源代码和二进制代码。

建议客户从开放源代码社区或使用开放源代码社区的合作伙伴那里获取框架的补救性服务。

有关 IBM 支持和策略的详细信息，请参考 IBM Support Handbook 和 WebSphere Application Server Support Statement。

尽管在开放源代码环境中使用 WebSphere Application Servers 时按照本文的建议做法有助于增强您的体验，但本文并没有列出开放源代码组件影响 WebSphere Application Server 操作或其他组件操作的所有情况。使用开放源代码的用户务必检查所有组件的规范，以避免出现许可、支持和技术问题。

本文中的术语“支持”或“受支持”指示描述的用法仅限于使用 IBM 有文档记录的功能。作者尽最大努力提供关于如何配置和使用这些框架的建议，以确保其用法与有文档记录的产品行为一致，但本文不是保证，也不是支持 Spring 或 Hibernate 的声明。

 

结束语

Spring Framework 正在迅速普及。开发人员喜欢使用易用的接口和基于 XML 的配置加速 J2EE 开发和轻松地进行单元测试。框架本身也正在迅速发展，现在，网站上列出了许多子项目。与使用所有软件一样，确定在应用程序中使用它可提供什么好处，以及是否具有完成相同结果的更好备选方法是非常重要的。当然，Spring 中的一些功能复制了已嵌入 WebSphere Application Server 的功能，所以无需将应用程序部署到该服务器来使用此额外的框架代码层。但是，如果使用得当，您可以将 Spring 许多易用的开发功能与 WebSphere Application Server 强健的集成企业支持功能结合使用，以快速开发企业应用程序，并将其部署到 IBM 中行业领先的 J2EE 应用服务器。

Hibernate 是可以与 WebSphere Application Server 一起成功使用的多个永久性框架之一，可以为关系数据库中存储的实体数据提供与对象相关的映射（如果经过充分考虑避免了问题场景）。尤其是，您必须确保使用 Hibernate 不涉及使用内部 WebSphere Application Server 接口。按照这里提供的建议，您可以避免一些常见问题，并将 Hibernate 用作部署到 WebSphere Application Server 的应用程序的永久性框架。