将Spring和Hibernate 与WAS一起使用

Spring Framework（通常称为Spring）是一个开放源代码项目，目的是为了使 J2EE™ 环境更具可访问性。Spring 为简单 Java™ 对象提供框架，使这些对象可以通过包装类和 XML 配置使用 J2EE 容器。Spring 的目标是为这些项目提供显著的好处，提高这些项目的开发效率和运行时性能，同时改进测试覆盖率和应用程序质量。
Hibernate 是开放源代码持久性和查询框架，提供传统 Java 对象（Plain Old Java Object，POJO）到关系数据库表的对象-关系映射，以及数据查询和检索功能。
尽管许多组织感兴趣的是了解使用这些框架能够获得什么好处，但 IBM 希望让使用这些框架的客户知道，他们可以通过 WebSphere Application Server 以稳健和可靠的方式做到这一点。本文介绍这些框架如何与 WebSphere Application Server 一起使用，并介绍针对各种用例的最佳实践，以帮助您尽快开始使用 Spring 或 Hibernate。
通常将 Spring 描述为轻量级容器环境，但是将其描述为用于简化开发的框架可能更适当。Spring Framework 由 Interface21 根据 Rod Johnson 发表的关于依赖项注入设计模式的出版物开发而成。Spring 可以在独立应用程序中使用，或与应用程序服务器一起使用。其主要概念是使用依赖项注入和面向方面的编程来简化和平稳地进行从开发到测试再到生产的转换。
涉及 Spring 的最常用场景之一是使用简单的 Java Bean 类配置并驱动业务逻辑。Spring 文档应该提供了使用 Spring Bean 构建应用程序的足够信息，其中没有提供任何特定于 WebSphere 的内容。以下部分将描述在 WebSphere Application Server 上使用 Spring 的一些使用场景。根据本文的建议开发的 Spring 应用程序应该能够毫无问题地在 WebSphere Application Server 或 WebSphere Application Server Network Deployment 环境中执行。
除明确指出以外，本文提供的信息适用于所有平台上的 WebSphere Application Server 版本 6.0.2.x、6.1.x 和 7.0.x。
本部分介绍与在基于 Web 的表示层中使用 Spring 相关的注意事项。
Web MVC 框架
Spring 的 Web MVC 框架很长时间以来一直是其他框架的替代框架。直接由 WebSphere Application Server 交付、使用和支持的 Web MVC 框架包括 JavaServer Faces (JSF) 和 Struts。Spring 文档描述了如何将 Spring 与这些 Web 框架集成。尽管 WebSphere Application Server 支持使用上面的任何 MVC，但 IBM 仅为 WebSphere Application Server 附带的框架提供产品支持。
Portlet MVC 框架
Spring 还提供了一个 Portlet MVC 框架（该框架镜像 Spring Web MVC 框架），而且在 WebSphere Portal V6.0 和 WebSphere Application Server V6.1 Portlet 容器中运行。（有关 Spring Portlet 的示例集，请参见Spring Portlet MVC。）在 WebSphere Application Server V6.1 Portlet 容器中运行 Portlet 需要创建附加的 Web 应用程序，以定义 Portlet 的布局和聚合。从 WebSphere Application Server 信息中心和文章Portlet 容器介绍中可以获得关于如何使用 Portlet 聚合器标记库的信息。通常的做法是结合使用 JSF 和 Portlet 进行呈现。关于如何将 Spring、Hibernate、JSF 和 WebSphere Portal 组合起来的信息，请参见使用 IBM WebSphere Portal 配置 Hibernate、Spring、Portlets 和 OpenInSessionViewFilter。
本部分介绍与访问事务中的数据的 Spring Bean 配置相关的注意事项。
Spring Framework 实际上使用一个容器管理层（在 J2EE 环境中委托给基础 J2EE 运行时）包装 Spring Bean。下面将介绍应如何配置 Spring Bean，以便 Spring Framework 可以正确地向 WebSphere Application Server 运行时做出委托并与之集成。
访问 WebSphere Application Server 中配置的数据源
WebSphere Application Server 管理在应用程序服务器执行环境中使用的资源。需要访问诸如 JDBC 数据源等资源的 Spring 应用程序应该利用 WebSphere 管理的资源。为此，请执行以下步骤：
在开发过程中，应该使用资源引用配置 WAR 模块。例如：
jdbc/springdb javax.sql.DataSource Container Shareable
对于 EJB JAR 文件，应该在需要访问数据源的每个 EJB 中声明同一资源引用。
然后在 Spring 应用程序配置中声明数据源代理 Bean，代理 Bean 引用 WebSphere 管理的资源提供者：

通过此代理 Bean 访问数据源将会导致使用模块配置的引用查找数据源，从而能够由 WebSphere Application Server 正确管理。请注意，jndiName 属性值与使用资源引用中声明的资源引用名称连接的模式 java:comp/env/ 匹配。
或者，在 Spring 2.5 以后的版本中，可以使用 方法完成此匹配。请注意 jndiName 属性如何匹配资源引用中声明的资源引用名称与 resource-ref="true" 属性相结合的实际值：

然后，Spring 应用程序可以在适当情况下使用数据源代理 Bean。
将应用程序部署到 WebSphere Application Server 时，必须以常规方式配置资源提供者和资源数据源，以便由 Spring 应用程序资源引用使用。在部署过程中，在模块的部署描述符中声明的资源引用将绑定到应用程序服务器配置的数据源。
使用 JDBC 本机连接
当各种 JDBC 操作需要与本机 JDBC 资源交互时，Spring 可提供访问本机连接的机制。当在 JdbcTemplate 类上设置了 NativeJdbcExtractor 类时，Spring JdbcTemplate 类才可以利用此功能。设置 NativeJdbcExtractor 类后，当与 WebSphere Application Server 一起使用时，Spring 总是向下找到本机 JDBC 连接。这将忽略以下 WebSphere 服务质量功能和优点：
连接处理跟踪和再关联 连接共享 参与事务 连接池管理
这带来的另一个问题是 WebSphereNativeJdbcExtractor 类将依赖于内部 WebSphere 适配器类。这些内部类可能因 WebSphere Application Server 的版本而异，并且以后可能更改，从而破坏依赖于此功能的应用程序。
在 WebSphere Application Server 上不支持使用 NativeJdbcExtractor 类实现（例如 WebSphereNativeJdbcExtractor），您应避免需要使用该类的场景。替代方案是使用 WebSphere Application ServerWSCallHelper 类来访问非标准供应商的数据源扩展。
WebSphere Application Server 为事务处理和管理与资源提供者的连接提供了一个稳健和可伸缩的环境。无论是否在使用全局事务，与 JDBC、JMS 和 Java Connector 资源适配器的连接均由 WebSphere Application Server 管理；甚至在缺少全局事务时，始终存在一个运行时上下文，在该上下文中可以访问所有资源提供者连接。WebSphere Application Server 将此运行时上下文称为本地事务容器 (LTC) 作用域；在缺少全局事务时始终存在一个 LTC，并且无论是存在全局事务还是 LTC，资源访问始终由运行时管理。为确保事务上下文管理的完整性，以便可以正确管理事务资源，WebSphere Application Server 不向 WebSphere Application Server 中部署的应用程序或应用程序框架公开 javax.transaction.TransactionManager 接口。
在 Spring 中，有许多方法可以驱动事务控制下的资源更新，这包括编程形式和声明形式。声明形式包括 Java Annotation 和 XML 描述符形式。如果将 Spring 2.5 与 WebSphere Application Server V6.0.2.19 或 V6.1.0.9 或者更高版本一起使用，则可以利用对 Spring 的声明式事务模型的完全支持。Spring 2.5 有一个新的用于 WebSphere Application Server 的 PlatformTransactionManager 类，名为 WebSphereUowTransactionManager。该类利用 WebSphere Application Server 的受支持 UOWManager 接口进行事务上下文管理。通过 WebSphere Application Server 的 UOWManager 类管理事务划分可以确保在访问资源提供者时始终可以使用适当的全局事务或 LTC 上下文。不过，早期版本的 Spring 使用了内部 WebSphere 接口，以牺牲 Web 和 EJB 容器功能为代价来管理资源，并且不支持由应用程序使用。这会使容器处于未知状态，从而有可能导致数据损坏。
Spring 2.5 或更高版本中的声明式事务划分在 WebSphere Application Server 中受支持，它使用下面的声明提供对 WebSphere 事务的支持：

引用此声明的 Spring Bean 然后将使用标准 Spring 依赖项注入来使用事务支持，例如：
... PROPAGATION_REQUIRED
或者，在 Spring 2.5 以后的版本中，可以利用 Spring 的 AspectJ 支持。在下面的示例中，可以将 应用于应用程序的各个部分。这指示所有以“get”开头的方法都是 PROPAGATION_REQUIRED，并且所有以“set”开头的方法都是 PROPAGATION_REQUIRES_NEW。所有其他方法使用缺省事务设置。

标记将那些设置应用于类 MyService 中定义的任何已执行操作。

用于声明事务设置的另一种替代机制是使用基于 Spring 注释的事务支持。这要求使用 Java 5+，因此无法与 WebSphere Application Server V6.0.2.x 一起使用。
将以下内容添加到 Spring.xml 配置：

然后应该使用 @Transactional 注释对需要事务属性的任何方法进行标记：
@Transactional(readOnly = true) public String getUserName() { ...
请注意，只能将 @Transactional 注释用于注释公共方法。
WebSphereUowTransactionManager 支持每个 Spring 事务属性：
PROPAGATION_REQUIRED PROPAGATION_SUPPORTS PROPAGATION_MANDATORY PROPAGATION_REQUIRES_NEW PROPAGATION_NOT_SUPPORTED PROPAGATION_NEVER
对于没有提供 org.springframework.transaction.jta.WebSphereUowTransactionManager 的早期 Spring 版本以及没有提供 com.ibm.wsspi.uow.UOWManager 的 WebSphere Application Server V6.0.2.19 或 V6.1.0.9 之前的版本，WebSphere Application Server 中的事务支持通过以下 Spring 配置实现：

此配置支持一组受限制的事务属性，其中不包括 PROPAGATION_NOT_SUPPORTED 和 PROPAGATION_REQUIRES_NEW。Spring 类 org.springframework.transaction.jta.WebSphereTransactionManagerFactoryBean 也宣称提供 PROPAGATION_NOT_SUPPORTED 和 PROPAGATION_REQUIRES_NEW 功能，它使用不受支持的内部 WebSphere Application Server 接口，不应将其与 WebSphere Application Server 一起使用。
使用 Spring JMS
与访问 JDBC 数据源类似，打算访问 JMS 目的地的 Spring 应用程序必须确保它们使用了 WebSphere 管理的 JMS 资源提供者。使用 Spring JndiObjectFactoryBean 作为 ConnectionFactory 代理的相同模式将确保可以正确地管理 JMS 资源。
对于 JMS 消息发送或同步 JMS 消息接收，可以使用 JMSTemplates。这包括通过 JNDI 和真正的动态解析使用 Spring 的动态目的地解析功能。
下面的示例演示了 ConnectionFactory 的资源引用配置。此引用在应用程序部署过程中映射为指向应用程序服务器的 JNDI 命名空间中存储的已配置托管 ConnectionFactory。ConnectionFactory 是执行消息处理所必需的，并且应该将其注入 Spring JMSTemplate。
jms/myCF javax.jms.ConnectionFactory Container Shareable
现在应用程序中的 ConnectionFactory 有了已定义的 JNDI 名称，可以对其进行查找并将其注入 JMSTemplate：
...
在运行时，JMSTemplate 可以基于目的地的 JNDI 名称（在应用程序资源引用中配置）或通过“动态解析”来基于 WebSphere Application Server 中配置的目的地的管理名称定位目的地；例如，对于绑定到 jms/myQueue 的 JNDI 引用的 JMS myQueue 队列：
JNDI 解析：
jmsTemplate.send("java:comp/env/jms/myQueue", messageCreator);
动态解析：
jmsTemplate.send("myQueue", messageCreator);
作为对 J2EE 消息驱动 Bean (MDB) 的替代，Spring 提供了用于异步地处理入站 JMS 消息的消息驱动 POJO 模型。仅有一个 DefaultMessageListenerContainer 类将管理从 JMS 队列到已配置的 POJO 的消息，该 POJO 必须是 javax.jms.MessageListener 实现。
在 WebSphere Application Server 环境中，您还必须指定一个 WorkManagerTaskExecutor 类，这意味着 DefaultMessageListenerContainer 类将向服务器管理的线程池作出委托。正如上面描述过的，还应该通过 WebSphereUowTransactionManager 使用服务器的事务管理来配置 DefaultMessageListenerContainer。

虽然可以使用此消息驱动 POJO 模型，但是在需要工作负载管理和/或高可用性的 WebSphere Application Server 配置中，建议直接使用 J2EE 消息驱动 Bean (MDB)。请注意，不支持任何其他 Spring JMS MessageListenerContainer 类型，因为它们可以启动非托管线程，而且还可能使用不应由 Java EE 环境中的应用程序调用的 JMS API。
将 JPA 与 Spring 一起使用
EJB 3.0 规范将 Java Persistence API (JPA) 定义为提供可移植持久 Java 实体的方法。WebSphere Application Server V7 和 WebSphere Application Server V6.1 EJB 3 功能包都提供了 EJB 3 和 JPA 的实现；还可以将 JPA 的 Apache OpenJPA 实现与 WebSphere Application Server V6.1 一起使用（请参见参考资料）。将 Spring 与 JPA 实现结合使用时，您应该直接使用 JPA，而不是使用 Spring 的 JPA Helper 类（在 org.springframework.orm.jpa 包中）。
WebSphere Application Server V6.1 及更高版本支持 JPA 应用程序托管的实体管理器，该管理器可能是 JTA 或本地资源事务类型。JTA 实体管理器使用应用程序服务器的基础 JTA 事务支持，其事务划分可以使用上面描述的标准 J2EE 技术或 Spring 的声明式事务模型进行定义。
使用 JPA 的数据访问对象 (DAO) 与 persistence.xml 打包在一起，后者为应用程序使用的 JPA EntityManager 定义持久性上下文。例如，可以按下面的方式设置用于 JTA 实体管理器（使用的数据源的 JNDI 名称为“java:comp/env/jdbc/springdb”）的 persistence.xml：
org.apache.openjpa.persistence.PersistenceProviderImpl java:comp/env/jdbc/springdb
通过将 openjpa.TransactionMode 和 openjpa.ConnectionFactoryMode 属性设置为“managed”，JPA 实体管理器将事务和连接管理委托给 WebSphere Application Server。DAO 可以使用上面描述的 Spring 声明式事务划分。
还可以使用注释风格的 JPA EntityManager 注入。这与标准 JPA 完全相同：
@PersistenceContext private EntityManager em;
您需要以下 XML 代码将在 Spring XML 配置中启用 EntityManager 注入：

Spring 将在此 XML 文件中定义的 EntityManagerFactory 的基础上创建 EntityManager 。如果存在多个 EntityManagerFactory，则 Spring 将失败。使用以下方法中的一种（且仅一种）方法创建 EntityManagerFactory：
使用 Spring 的基本配置
使用 Spring 的高级配置
当然，通过使用 WebSphere Application Server V7 和 WebSphere Application Server V6.1 EJB 3 Feature Pack 中的纯粹 EJB 3 支持也可以获得注释和 JPA 的优点。在任一种情况下，您都可以使用 JPA API 创建 EntityManagerFactory，如下所示。建议不要将此方法用于非 EJB 3 环境，因为可能无法正确管理所创建的任何 EntityManager。但是，当您拥有 EJB 3 环境时，可以使用此方法分离 Spring 和 JPA 配置。

IBM JDK 6
WebSphere Application Server V7 在 IBM JDK 6 上运行，由于已在此 JIRA 中作文档说明的 Spring 问题，无法将 IBM JDK 6 与 V2.5.5 以前的 Spring 框架一起使用。
JMX 和 MBean
仅当 Spring JMX MBean 向 WebSphere Application Server 的容器管理器 MbeanServer 注册后，WebSphere Application Server V6.1 和更高版本才支持它。如果不指定任何服务器属性，则 MBeanExporter 将尝试自动检测运行的 MbeanServer。因此，在 WebSphere Application Server 上运行应用程序时，Spring 框架将找到容器的 MbeanServer。
您不应使用 MBeanServerFactory 实例化 MbeanServer，然后将其注入 MbeanExporter。而且，WebSphere Application Server 不支持使用 Spring 的 ConnectorServerFactoryMBean 或 JMXConnectorServer 通过打开入站 JMX 端口将本地 MBeanServer 公开给客户端。
WebSphere Application Server Version 6.1 以前的版本不支持 Spring JMX Mbean。
在 WebSphere Application Server 中注册 Spring MBean
当按下面的方式注册时，WebSphere Application Server MBean 将由 javax.management.ObjectName 标识：
WebSphere:cell=99T73GDNode01Cell,name=JmxTestBean,node=99T73GDNode01,
process=server1,type=JmxTestBeanImpl
这意味着，如果它们被取消注册，则需要使用相同的“完全限定”名称（而不是 MBean 的简单名称属性）查找它们。最好的方法是实现 org.springframework.jmx.export.naming.ObjectNamingStrategy，它是封装 ObjectName 实例创建的接口，并且在注册 Bean 时，MBeanExporter 可以使用它获得 ObjectName。Spring Framework 论坛上提供了一个示例。可以将 ObjectNamingStrategy 实例添加到您注册的 Bean。这可以确保在卸载应用程序时正确地取消注册 MBean。
...
MBean ObjectName 和通知
由于在 WebSphere Application Server 中使用的是 MBean 的完全限定 ObjectName，因此建议您完整定义该 ObjectName 以使用通知。此 JIRA 支持改为使用 Spring Bean 名称，，但是仅当您在使用相应版本的 Spring 的时候，才应该提供修复程序。

System z 多调用/单调用限制
由于 Spring 不允许在 MBean 描述符中指定特定于平台的字段，因此 Spring JMX 将在 WebSphere Application Server V6.1 中的多 SR 服务器上运行，但在部署选项中受限。WebSphere Application Server 缺省使用单调用策略，这样仅要求一个 MBean 实例（在一个不确定的 SR 中）就可以执行某个请求。在某些场景中这已足够，但是应用程序更可能需要能够声明多调用和单调用方法的组合，并且可能产生聚合逻辑。
调度和线程池
Spring 提供了许多可用于调度工作的 TaskExecutor 类。只有 WebSphere Application Server 支持用于异步执行工作的 Spring TaskExecutor 才是 Spring WorkManagerTaskExecutor 类，该类可正确地利用 WebSphere Application Server 托管的线程池，并向已配置的 WorkManager 作出委托。其他 TaskExecutor 实现可以启动非托管线程。
在 WebSphere Application Server 管理控制台中，可以通过导航到 Resources => Asynchronous beans => Work managers 对 WorkManager 进行设置。然后可以在 Spring 配置文件中作为 workManagerName 属性使用资源的 JNDI 名称来定义 WorkManagerTaskExecutor。下面的示例使用 WebSphere Application Server 的 DefaultWorkManager JNDI 名称或 wm/default：

类加载器
Spring 和 WebSphere Application Server 都使用多个开放源代码项目，遗憾的是，它们共有的项目版本并不总是匹配。应该将 Spring 依赖项包装为应用程序的一部分，并且应该按照下面的描述设置服务器以避免冲突。否则，类加载器可能无法为运行时或应用程序加载适当的版本。通常，这将导致异常，在日志中显示类、ClassCastExceptions 或 java.lang.VerifyErrors 的版本不匹配。
其中一个示例是使用 Jakarta Commons Logging。要配置供应用程序使用的 Jakarta Commons Logging (JCL)，或者使用不是由应用程序服务器提供的其他版本的 JCL（例如，使用应用程序代码嵌入的 JCL），将需要在 WebSphere Application Server 上进行专门的配置。有关如何配置已部署的应用程序，以使用嵌入版本的常用技术的策略，请参见集成 Jakarta Commons Logging。请密切关注支持网站，了解是否提供了有关如何在 WebSphere Application Server V6.x 产品上配置嵌入式 JCL 的更新。这仅仅是冲突的一个示例。其他示例可能包括应用程序使用 JDOM 或特定版本的 JavaMail。不支持将 WebSphere Application Server 的 JAR 文件替换为这些或具有更高版本或不同版本的其他包。
在 WebSphere Application Server 上困扰 Spring 用户的另一个类加载器问题是 Spring 加载资源的方法。资源可以包括消息绑定之类的内容，通过类加载器层次结构和在层次结构中查找资源的各种策略，可以在非预期的位置找到使用公共名称的资源。可以使用 WebSphere Application Server 类加载器查看器来帮助解决此问题。资源与其他版本的公共库的组合可能要求应用程序将资源重命名为唯一的名称。
James Estes 在Spring 论坛上阐述的示例包含打包为 EAR 文件的 EJB 项目和 Web 项目。所描述的解决方案是将 spring.jar 文件同时添加到 WEB-INF/lib 和顶级 EAR 中，然后将 WEB 项目的类加载器策略设置为 PARENT LAST，以便先找到 WEB-INF/lib 中的版本。EJB 项目使用 EAR 中的版本。
Spring Framework 提供的某些基础结构服务将复制由基于标准的应用程序服务器运行时提供的服务。而且，从基础 J2EE 应用程序服务器抽象出 Spring 框架基础结构必然要削弱与应用程序服务器运行时服务质量的集成，如安全性、工作负载管理和高可用性。因此，在应用程序设计过程中，必须认真考虑部署到 WebSphere Application Server 中的应用程序中的 Spring Framework 使用，以避免降低 WebSphere Application Server 提供的任何服务质量。如果没有任何其他建议，首选的方法是直接使用 WebSphere Application Server 提供的服务，以便基于开放标准开发应用程序，并确保未来部署的灵活性。
非托管线程
某些 Spring 场景可能导致创建非托管的线程。非托管线程对 WebSphere Application Server 是未知的，并且不能访问 Java EE 上下文信息。此外，它们可以在 WebSphere Application Server 不知道的情况下利用资源，在管理员无法控制其数量和资源使用的情况下存在，在发生故障时，它们还阻止应用程序服务器正常关闭或恢复资源。应用程序应该避免导致启动非托管线程的任何场景，如：
registerShutdownHook
避免使用 Spring AbstractApplicationContext 或其子类之一。registerShutdownHook 是一个公共方法，它可以创建线程并将其注册到 Java 虚拟机，以便在关机时运行以关闭 ApplicationContext。应用程序可以避免这一点，方法是利用从 WebSphere 容器接收的常规生命周期通知来显式调用 ApplicationContext 上的关闭。
WeakReferenceMonitor
Spring 为简化开发 EJB 组件提供了方便的类，但是请注意，这些方便的类会生成由 WeakReferenceMonitor 用来执行清除操作的非托管线程。
调度
Spring 提供（或集成）了大量的调度包，但是，只有与 WebSphere Application Server 托管的线程一起使用的 Spring 调度包才是 CommonJ WorkManager。其他包（如 quartz 和 JDK Timer）会启动非托管线程，应该避免使用。
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 配置文件中进行了定义）设置为引用在模块的部署描述符中定义的资源引用（例如 java:comp/env/jdbc/myDSRef），将 Hibernate 配置为从 WebSphere Application Server 检索数据源。例如：
java:/comp/env/jdbc/myDSRef
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 中设置以下属性：
对于容器管理的事务：
org.hibernate.transaction.CMTTransactionFactory org.hibernate.transaction.WebSphereExtendedJTATransactionLookup
对于 Bean 管理的事务：
org.hibernate.transaction.JTATransactionFactory org.hibernate.transaction.WebSphereExtendedJTATransactionLookup java:comp/UserTransaction
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 说明了使用两种模式的业务流程，但该流程的详细信息不在本文的讨论范围之内。

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