Hibernate的使用

使用 Hibernate

本文来自：http://www.ibm.com/developerworks/cn/websphere/techjournal/0609_alcott/0609_alcott.html

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

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

• 使用 WebSphere Application Server 数据源

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

  <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 接口建立了一种在 Java EE 5 中通过 JTA 1.1 规范正式确立的模式。

• 不支持的事务配置

  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 最适用于书签，而不适用于缓存。在使用智能序列化改进 HttpSession 性能中讨论了如何使 HttpSession 的内存使用率降至最低。与将 HttpSession 用作缓存不同，应该考虑使用 ObjectGrid 或 DistributedObjectCache 之类的 WebSphere 数据缓存技术，这在下一部分进行介绍。

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

在本文发表之际，Hibernate 的识别集群的缓存与 WebSphere Application Server 相结合的行为还没有确定，因此，还不能确定是否支持使用该缓存，我们对此不做进一步的讨论。因此，需要分布式缓存的客户应当考虑创建使用属性 hibernate.cache.provider_class 实现 org.hibernate.cache.CacheProvider 的类,该属性将采用 WebSphere 中的两个分布式缓存实现中的一个。

• 集成二级缓存

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

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

  • DistributedMap/DistributedObjectCache 接口提供了支持 WebSphere v6.x 产品系列的分布式缓存。有关详细信息，请参见将 DistributedMap 和 DistributedObjectCache 接口用于动态缓存。

  • 作为 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 状态没有加载，则在合并回去时可能显示为已更改。要使它正常工作，供应商必须实现特定于其运行时的序列化技术。这不是可互操作的，语义也可能不是可移植的。