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

使用 Spring 处理事务

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.1 RC1 与 WebSphere Application Server V6.0.2.19 或 V6.1.0.9 或者更高版本一起使用，则可以利用对 Spring 的声明式事务模型的完全支持。Spring 2.1 RC1 有一个新的用于 WebSphere Application Server 的 PlatformTransactionManager 类，称为 WebSphereUowTransactionManager。该类利用 WebSphere Application Server 的受支持 UOWManager 接口进行事务上下文管理。通过 WebSphere Application Server 的 UOWManager 类管理事务划分可以确保在访问资源提供程序时始终可以使用适当的全局事务或 LTC 上下文。不过，较早版本的 Spring 使用了内部 WebSphere 接口以牺牲 Web 和 EJB 容器功能为代价来管理资源，并且不支持由应用程序使用。这会使容器处于未知状态，从而有可能导致数据损坏。

Spring 2.1 RC1 或更高版本中的声明式事务划分在 WebSphere Application Server 中受支持，它使用下面的声明提供对 WebSphere 事务的支持：

<bean id="transactionManager"

    class="org.springframework.transaction.jta.WebSphereUowTransactionManager"/>

引用此声明的 Spring Bean 然后将使用标准 Spring 依赖项注入来使用事务支持，例如：

<bean id="someBean" class="some.class">

    <property name="transactionManager" >

        <ref bean="transactionManager"/>

    </property>

...

</bean>

<property name="transactionAttributes">

    <props>

        <prop key="*">PROPAGATION_REQUIRED</prop>

    </props>

</property>

WebSphereUowTransactionManager 支持每个 Spring 事务属性：

o PROPAGATION_REQUIRED

o PROPAGATION_SUPPORTS

o PROPAGATION_MANDATORY

o PROPAGATION_REQUIRES_NEW

o PROPAGATION_NOT_SUPPORTED

o 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 配置实现：

<bean id="transactionManager" 

    class="org.springframework.transaction.jta.JtaTransactionManager">

        <property name="autodetectTransactionManager"value="false" />

</bean>

此配置支持一组受限制的事务属性，其中不包括 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 用作 QueueConnectionFactory 或 TopicConnectionFactory 的代理将确保可以正确管理 JMS 资源。

JMS 的另一注意事项是 Spring 对入站 JMS 消息的支持：Spring 提供的 DefaultMessageListenerContainer 类可用于承载 J2SE 或 J2EE 环境中的消息使用者端点。在 WebSphere Application Server 环境中，这样可以正确使用服务器管理的线程，并且可以与服务器的事务管理集成，如上面所述。这是一个受支持的 Spring 应用程序配置，但建议将 J2EE 消息驱动的 Bean (MDB) 直接在要求工作负载管理和/或高可用性的 WebSphere Application Server 配置中使用。注意，不支持任何其他 Spring JMS MessageListenerContainer 类型，因为它们可以启动非托管线程，而且还可能使用不应由 Java EE 环境中的应用程序调用的 JMS API。

将 OpenJPA 与 Spring 一起使用

EJB 3.0 规范的一部分规定了新的 Java Persistence API (JPA)。Apache OpenJPA 项目是 JPA 的一个开源实现，您可以直接将其与 Spring 和 WebSphere Application Server V6.1 一起使用（请参见参考资料）；直接使用 OpenJPA 类比使用 Spring 的 JPA 帮助程序类（在 org.springframework.orm.jpa 程序包中）更可取，原因是前者在 WebSphere Application Server 上进行了更彻底的测试。OpenJPA 依赖于 JDK 1.5，因此将与 WebSphere Application Server V6.1 和更高版本一起使用。

WebSphere Application Server V6.1 支持 JPA 应用程序托管的实体管理器，它可能是 JTA 或本地资源事务类型。OpenJPA JTA 实体管理器使用应用服务器的基础 JTA 事务支持，使用上面描述的标准 J2EE 技术或 Spring 的声明式事务模型可以为其定义事务划分。

使用 OpenJPA 的数据访问对象 (DAO) 与 persistence.xml 打包在一起，后者为应用程序使用的 JPA EntityManager 定义永久性上下文。例如，可以按下面的方式设置用于 JTA 实体管理器（使用的数据源的 JNDI 名称为“java:comp/env/jdbc/springdb”）的 persistence.xml：

<persistence 

   xmlns="http://java.sun.com/xml/ns/persistence"

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:schemaLocation="http://java.sun.com/xml/ns/persistence

   http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">

    <persistence-unit name="default" transaction-type="JTA">

    <provider> org.apache.openjpa.persistence.PersistenceProviderImpl </provider>

    <jta-data-source> java:comp/env/jdbc/springdb </jta-data-source>

    <properties>

        <property name="openjpa.TransactionMode" value="managed" />

        <property name="openjpa.ConnectionFactoryMode"value="managed" />

        <property name="openjpa.jdbc.DBDictionary" value="db2" />

    </properties>

    </persistence-unit>

</persistence>

通过将 openjpa.TransactionMode 和 openjpa.ConnectionFactoryMode 属性设置为“managed”（托管），OpenJPA 将事务和连接管理委派给 WebSphere Application Server。DAO 可以使用上面描述的 Spring 声明式事务划分。

集成和管理注意事项

JMX 和 MBeans

仅当 Spring JMX MBeans 向 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 6.1 版以前的版本不支持 Spring JMX Mbeans。

在 WebSphere Application Server 中注册 Spring MBeans

在按下面的方式注册时，javax.management.ObjectName 可以识别 WebSphere Application Server MBeans：

WebSphere:cell=99T73GDNode01Cell,name=JmxTestBean,node=99T73GDNode01,

process=server1, type=JmxTestBeanImpl

这意味着，如果它们被取消注册，则需要使用相同的“完全限定”名称（而不是 MBean 的简单名称属性）查找它们。最好的方法是实现 org.springframework.jmx.export.naming.ObjectNamingStrategy，它是封装创建 ObjectName 实例的接口，并且在注册 Bean 时，MBeanExporter 可以使用它获得 ObjectNames。Spring Framework 论坛上提供了一个示例。您可以将 ObjectNamingStrategy 实例添加到注册的 Bean。 这可以确保在卸载应用程序时适当取消注册 MBean。

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter"

   lazy-init="false">

<property name="beans">

    <map> <entry key="JmxTestBean" value-ref="testBean" /> </map>

</property>

<property name="namingStrategy" ref="websphereNamingStrategy" />

...

</bean>

 

MBeans ObjectNames 和通知

由于在 WebSphere Application Server 中使用的是 MBeans 的完全限定 ObjectName，因此需要定义该 ObjectName 才能完全使用通知。在撰写本文时，有一个开放 JIRA 可以使用 Spring Bean 名称，能够简化此情形。

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" 

   lazy-init="false">

    <property name="beans">

        <map> 

            <entry key="JmxTestBean" value-ref="testBean" />

        </map>

    </property> 

    <property name="namingStrategy" ref="websphereNamingStrategy" />

    <property name="notificationListenerMappings">

        <map>

            <entry key="WebSphere:cell=99T73GDNode01Cell, name=JmxTestBean, 

               node=99T73GDNode01, process=server1, type=JmxTestBeanImpl">

                <bean class="client.MBeanListener" /> 

            </entry>

        </map>

    </property> 

</bean>

 

System z 多个调用/单个调用限制

由于 Spring 不允许在 MBean 描述符中指定特定于平台的字段，因此 Spring JMX 可以在 WebSphere Application Server V6.1 中的多个 SR 服务器上运行，但在部署选项中受限。WebSphere Application Server 缺省使用单个调用 (unicall) 策略，这样仅要求一个 MBean 实例（一个不确定的 SR）就可以执行请求。在某些场景中这已足够，但多数应用程序可能需要声明多个调用 (multicall) 和单个调用方法的组合，因此可能需要聚合逻辑。

计划和线程池

Spring 提供可用于计划工作的大量 TaskExecutor 类。只有 WebSphere Application Server 支持的、用于异步执行工作的 Spring TaskExecutor 才是 Spring WorkManagerTaskExecutor 类，该类可正确地利用 WebSphere Application Server 托管的线程池，并委派给配置的 WorkManager。其他 TaskExecutor 实现可以启动非托管线程。

在 WebSphere Application Server 管理控制台中，通过导航到 Resources => Asynchronous beans => Work managers 可以对 WorkManager 进行设置。然后可以在 Spring 配置文件中使用资源的 JNDI 名称来定义 WorkManagerTaskExecutor。

类加载器

Spring 和 WebSphere Application Server 都使用多个开放源代码项目，遗憾的是，它们共有的项目版本并不总是匹配。应该将 Spring 依赖项包装为应用程序的一部分，并且应该按照下面的描述设置服务器以避免冲突。否则，类加载器可能无法为运行时或应用程序加载适当的版本。通常，这将导致异常，在日志中显示类的版本不匹配、ClassCastExceptions 或 java.lang.VerifyErrors。

其中一个示例是使用 Jakarta Commons Logging。配置供应用程序使用的 Jakarta Commons Logging (JCL)，或者使用不是由应用服务器提供的其他版本的 JCL（例如，使用应用程序代码嵌入的 JCL）需要在 WebSphere Application Server 上进行特定的配置。有关如何配置部署的应用程序，以使用内嵌版本的常用技术的策略，请参见 Integrating 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 不知道的情况下利用资源，存在管理