16.4 JPA

Spring JPA在org.springframework.orm.jpa包中已经可用,Spring JPA用了Hibernate集成相似的方法来提供更易于理解的JPA支持,与此同时,了解了JPA底层实现,可以理解更多的Spring JPA特性。

16.4.1 Spring中JPA配置的三个选项

Spring JPA支持提供了三种配置JPAEntityManagerFactory的方法,之后通过EntityManagerFactory来获取对应的实体管理器。

LocalEntityManagerFactoryBean

通常只有在简单的部署环境中使用此选项,例如在独立应用程序或者进行集成测试时,才会使用这种方式。

LocalEntityManagerFactoryBean创建一个适用于应用程序且仅使用JPA进行数据访问的简单部署环境的EntityManagerFactory。工厂bean会使用JPAPersistenceProvider自动检测机制,并且在大多数情况下,仅要求开发者指定持久化单元的名称:

<beans> 
    <bean id="myEmf" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean"> 
        <property name="persistenceUnitName" value="myPersistenceUnit"/> 
    </bean> 
</beans> 

这种形式的JPA部署是最简单的,同时限制也很多。开发者不能引用现有的JDBCDataSource bean定义,并且不支持全局事务。而且,持久化类的织入(weaving)(字节码转换)是特定于提供者的,通常需要在启动时指定特定的JVM代理。该选项仅适用于符合JPA Spec的独立应用程序或测试环境。

从JNDI中获取EntityManagerFactory

在部署到J2EE服务器时可以使用此选项。检查服务器的文档来了解如何将自定义JPA提供程序部署到服务器中,从而对服务器进行比默认更多的个性化定制。

从JNDI获取EntityManagerFactory(例如在Java EE环境中),只需要在XML配置中加入配置信息即可:

<beans> 
    <jee:jndi-lookup id="myEmf" jndi-name="persistence/myPersistenceUnit"/> 
</beans> 

此操作将采用标准J2EE引导:J2EE服务器自动检测J2EE部署描述符(例如web.xml)中persistence-unit-ref条目和持久性单元(实际上是应用程序jar中的META-INF/persistence.xml文件),并为这些持久性单元定义环境上下文位置。

在这种情况下,整个持久化单元部署(包括持久化类的织入(weaving)(字节码转换))都取决于J2EE服务器。JDBC DataSource通过META-INF/persistence.xml文件中的JNDI位置进行定义; 而EntityManager事务与服务器JTA子系统集成。 Spring仅使用获取的EntityManagerFactory,通过依赖注入将其传递给应用程序对象,通常通过JtaTransactionManager来管理持久性单元的事务。

如果在同一应用程序中使用多个持久性单元,则这种JNDI检索的持久性单元的bean名称应与应用程序用于引用它们的持久性单元名称相匹配,例如@PersistenceUnit和@PersistenceContext注释。

LocalContainerEntityManagerFactoryBean

在基于Spring的应用程序环境中使用此选项来实现完整的JPA功能。这包括诸如Tomcat的Web容器,以及具有复杂持久性要求的独立应用程序和集成测试。

LocalContainerEntityManagerFactoryBean可以完全控制EntityManagerFactory的配置,同时适用于需要细粒度定制的环境。 LocalContainerEntityManagerFactoryBean会基于persistence.xml文件,dataSourceLookup策略和指定的loadTimeWeaver来创建一个PersistenceUnitInfo实例。因此,可以在JNDI之外使用自定义数据源并控制织入(weaving)过程。以下示例显示LocalContainerEntityManagerFactoryBean的典型Bean定义:

<beans> 
    <bean id="myEmf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> 
        <property name="dataSource" ref="someDataSource"/> 
        <property name="loadTimeWeaver"> 
            <bean class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver"/> 
        </property> 
    </bean> 
</beans> 

下面的例子是一个典型的persistence.xml文件:

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> 
    <persistence-unit name="myUnit" transaction-type="RESOURCE_LOCAL"> 
        <mapping-file>META-INF/orm.xml</mapping-file> 
        <exclude-unlisted-classes/> 
    </persistence-unit> 
</persistence> 

<exclude-unlisted-classes />标签表示不会进行注解实体类的扫描。指定的显式true值 - <exclude-unlisted-classes>true</exclude-unlisted-classes/>- 也意味着不进行扫描。<exclude-unlisted-classes> false</exclude-unlisted-classes>则会触发扫描;但是,如果开发者需要进行实体类扫描,建议开发者简单地省略<exclude-unlisted-classes>元素。

LocalContainerEntityManagerFactoryBean是最强大的JPA设置选项,允许在应用程序中进行灵活的本地配置。它支持连接到现有的JDBCDataSource,支持本地和全局事务等。但是,它对运行时环境施加了需求,其中之一就是如果持久性提供程序需要字节码转换,就需要有织入(weaving)能力的类加载器。

此选项可能与J2EE服务器的内置JPA功能冲突。在完整的J2EE环境中,请考虑从JNDI获取EntityManagerFactory。或者,在开发者的LocalContainerEntityManagerFactoryBean定义中指定一个自定义persistenceXmlLocation,例如META-INF/my-persistence.xml,并且只在应用程序jar文件中包含有该名称的描述符。因为J2EE服务器仅查找默认的META-INF/persistence.xml文件,所以它会忽略这种自定义持久性单元,从而避免了与Spring驱动的JPA设置之间发生冲突。 (例如,这适用于Resin 3.1)

何时需要加载时间织入?
并非所有JPA提供商都需要JVM代理。Hibernate就是一个不需要JVM代理的例子。如果开发者的提供商不需要代理或开发者有其他替代方案,例如通过定制编译器或Ant任务在构建时应用增强功能,则不用使用加载时间编织器。

LoadTimeWeaver是一个Spring提供的接口,它允许以特定方式插入JPAClassTransformer实例,这取决于环境是Web容器还是应用程序服务器。 通过代理挂载ClassTransformers通常性能较差。代理会对整个虚拟机进行操作,并检查加载的每个类,这是生产服务器环境中最不需要的额外负载。

Spring为各种环境提供了一些LoadTimeWeaver实现,允许ClassTransformer实例仅适用于每个类加载器,而不是每个VM。

有关LoadTimeWeaver的实现及其设置的通用或定制的各种平台(如Tomcat,WebLogic,GlassFish,Resin和JBoss)的更多了解,请参阅AOP章节中的Spring配置一节。

如前面部分所述,开发者可以使用@EnableLoadTimeWeaving注解或者load-time-weaverXML元素来配置上下文范围的LoadTimeWeaver。所有JPALocalContainerEntityManagerFactoryBeans都会自动拾取这样的全局织入器。这是设置加载时间织入器的首选方式,为平台(WebLogic,GlassFish,Tomcat,Resin,JBoss或VM代理)提供自动检测功能,并将织入组件自动传播到所有可以感知织入者的Bean:

<context:load-time-weaver/> 
<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> 
    ... 
</bean> 

开发者也可以通过LocalContainerEntityManagerFactoryBean的loadTimeWeaver属性来手动指定专用的织入器:

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> 
    <property name="loadTimeWeaver"> 
        <bean class="org.springframework.instrument.classloading.ReflectiveLoadTimeWeaver"/> 
    </property> 
</bean> 

无论LTW如何配置,使用这种技术,依赖于仪器的JPA应用程序都可以在目标平台(例如:Tomcat)中运行,而不需要代理。这尤其重要的是当主机应用程序依赖于不同的JPA实现时,因为JPA转换器仅应用于类加载器级,彼此隔离。

处理多个持久化单元

例如,对于依赖存储在类路径中的各种JARS中的多个持久性单元位置的应用程序,Spring将PersistenceUnitManager作为中央仓库来避免可能昂贵的持久性单元发现过程。默认实现允许指定多个位置,这些位置将通过持久性单元名称进行解析并稍后检索。(默认情况下,搜索classpath下的META-INF/persistence.xml文件。)

<bean id="pum" class="org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager"> 
    <property name="persistenceXmlLocations"> 
        <list> 
            <value>org/springframework/orm/jpa/domain/persistence-multi.xml</value> 
            <value>classpath:/my/package/**/custom-persistence.xml</value> 
            <value>classpath*:META-INF/persistence.xml</value> 
        </list> 
    </property> 
    <property name="dataSources"> 
        <map> 
            <entry key="localDataSource" value-ref="local-db"/> 
            <entry key="remoteDataSource" value-ref="remote-db"/> 
        </map> 
    </property> 
    <!-- if no datasource is specified, use this one --> 
    <property name="defaultDataSource" ref="remoteDataSource"/> 
</bean> 

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> 
    <property name="persistenceUnitManager" ref="pum"/> 
    <property name="persistenceUnitName" value="myCustomUnit"/> 
</bean> 

在默认实现传递给JPA provider之前,是允许通过属性(影响全部持久化单元)或者通过PersistenceUnitPostProcessor以编程(对选择的持久化单元进行)进行对PersistenceUnitInfo进行自定义的。如果没有指定PersistenceUnitManager,则由LocalContainerEntityManagerFactoryBean在内部创建和使用。

16.4.2 基于JPA的EntityManagerFactory和EntityManager来实现DAO

虽然EntityManagerFactory实例是线程安全的,但EntityManager实例不是。注入的JPA EntityManager的行为类似于从JPA Spec中定义的应用程序服务器的JNDI环境中提取的EntityManager。它将所有调用委托给当前事务的EntityManager(如果有);否则,它每个操作返回的都是新创建的EntityManager,通过使用不同的EntityManager来保证使用时的线程安全。

通过注入的方式使用EntityManagerFactory或EntityManager来编写JPA代码,是不需要依赖任何Spring定义的类的。如果启用了PersistenceAnnotationBeanPostProcessor,Spring可以在实例级别和方法级别识别@PersistenceUnit和@PersistenceContext注解。使用@PersistenceUnit注解的纯JPA DAO实现可能如下所示:

public class ProductDaoImpl implements ProductDao { 

    private EntityManagerFactory emf; 

    @PersistenceUnit 
    public void setEntityManagerFactory(EntityManagerFactory emf) { 
        this.emf = emf; 
    } 

    public Collection loadProductsByCategory(String category) { 
        EntityManager em = this.emf.createEntityManager(); 
        try { 
            Query query = em.createQuery("from Product as p where p.category = ?1"); 
            query.setParameter(1, category); 
            return query.getResultList(); 
        } 
        finally { 
            if (em != null) { 
                em.close(); 
            } 
        } 
    } 
} 

上面的DAO对Spring的实现是没有任何依赖的,而且很适合与Spring的应用程序上下文进行集成。而且,DAO还可以通过注解来注入默认的EntityManagerFactory:

<beans> 

    <!-- bean post-processor for JPA annotations --> 
    <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/> 

    <bean id="myProductDao" class="product.ProductDaoImpl"/> 
</beans> 

如果不想明确定义PersistenceAnnotationBeanPostProcessor,可以考虑在应用程序上下文配置中使用Spring上下文annotation-configXML元素。这样做会自动注册所有Spring标准后置处理器,用于初始化基于注解的配置,包括CommonAnnotationBeanPostProcessor等。

<beans> 
    <!-- post-processors for all standard config annotations --> 
    <context:annotation-config/> 

    <bean id="myProductDao" class="product.ProductDaoImpl"/> 
</beans> 

这样的DAO的主要问题是它总是通过工厂创建一个新的EntityManager。开发者可以通过请求事务性EntityManager(也称为共享EntityManager,因为它是实际的事务性EntityManager的一个共享的,线程安全的代理)来避免这种情况。

public class ProductDaoImpl implements ProductDao { 

    @PersistenceContext 
    private EntityManager em; 

    public Collection loadProductsByCategory(String category) { 
        Query query = em.createQuery("from Product as p where p.category = :category"); 
        query.setParameter("category", category); 
        return query.getResultList(); 
    } 
} 

@PersistenceContext注解具有可选的属性类型,默认值为PersistenceContextType.TRANSACTION。此默认值是开发者所需要接收共享的EntityManager代理。替代方案PersistenceContextType.EXTENDED则完全不同:该方案会返回一个所谓扩展的EntityManager,该EntityManager不是线程安全的,因此不能在并发访问的组件(如Spring管理的单例Bean)中使用。扩展实体管理器仅应用于状态组件中,比如持有会话的组件,其中EntityManager的生命周期与当前事务无关,而是完全取决于应用程序。

方法和实例变量级别注入
指示依赖注入(例如@PersistenceUnit和@PersistenceContext)的注解可以应用于类中的实例变量或方法,也就是表达式方法级注入和实例变量级注入。实例变量级注释简洁易用,而方法级别允许进一步处理注入的依赖关系。在这两种情况下,成员的可见性(public,protected,private)并不重要。
类级注解怎么办?
在J2EE平台上,它们用于依赖关系声明,而不是资源注入。

注入的EntityManager是由Spring管理的(Spring可以意识到正在进行的事务)。重要的是要注意,因为通过注解进行注入,即使新的DAO实现使用通过方法注入的EntityManager而不是EntityManagerFactory的注入的,在应用程序上下文XML中不需要进行任何修改。

这种DAO风格的主要优点是它只依赖于Java Persistence API;不需要导入任何Spring的实现类。而且,Spring容器可以识别JPA注解来实现自动的注入和管理。从非侵入的角度来看,这种风格对JPA开发者来说可能更为自然。

16.4.3 Spring驱动的JPA事务

如果开发者还没有阅读声明式事务管理,强烈建议开发者先行阅读,这样可以更详细地了解Spring的对声明式事务支持。

JPA的推荐策略是通过JPA的本地事务支持的本地事务。 Spring的JpaTransactionManager提供了许多来自本地JDBC事务的功能,例如针对任何常规JDBC连接池(不需要XA要求)指定事务的隔离级别和资源级只读优化等。

Spring JPA还允许配置JpaTransactionManager将JPA事务暴露给访问同一DataSource的JDBC访问代码,前提是注册的JpaDialect支持检索底层JDBC连接。Spring为EclipseLink和Hibernate JPA实现提供了实现。有关JpaDialect机制的详细信息,请参阅下一节。

16.4.4 JpaDialect和JpaVendorAdapter

作为高级功能,JpaTransactionManager和AbstractEntityManagerFactoryBean的子类支持自定义JpaDialect,将其作为Bean传递给jpaDialect属性。JpaDialect实现可以以供应商特定的方式使能Spring支持的一些高级功能:

  • 应用特定的事务语义,如自定义隔离级别或事务超时
  • 为基于JDBC的DAO导出事务性JDBC连接
  • 从PersistenceExceptions到SpringDataAccessExceptions的异常转义

这对于特殊的事务语义和异常的高级翻译特别有价值。但是Spring使用的默认实现(DefaultJpaDialect)是不提供任何特殊功能的。如果需要上述功能,则必须指定适当的方言才可以。

作为一个更广泛的供应商适应设施,主要用于Spring的全功能LocalContainerEntityManagerFactoryBean设置,JpaVendorAdapter将JpaDialect的功能与其他提供者特定的默认设置相结合。指定HibernateJpaVendorAdapter或EclipseLinkJpaVendorAdapter是分别为Hibernate或EclipseLink自动配置EntityManagerFactory设置的最简单方便的方法。但是请注意,这些提供程序适配器主要是为了与Spring驱动的事务管理一起使用而设计的,即为了与JpaTransactionManager配合使用的。

有关其操作的更多详细信息以及在Spring的JPA支持中如何使用,请参阅JpaDialect和JpaVendorAdapter的Javadoc。

16.4.5 为JPA配置JTA事务管理

作为JpaTransactionManager的替代方案,Spring还允许通过JTA在J2EE环境中或与独立的事务协调器(如Atomikos)进行多资源事务协调。除了用Spring的JtaTransactionManager替换JpaTransactionManager,还有需要以下一些操作:

  • 底层JDBC连接池是需要具备XA功能,并与开发者的事务协调器集成的。这在J2EE环境中很简单,只需通过JNDI导出不同类型的DataSource即可。有关导出DataSource等详细信息,可以参考应用服务器文档。类似地,独立的事务协调器通常带有特殊的XA集成的DataSource实现。
  • 需要为JTA配置JPAEntityManagerFactory。这是特定于提供程序的,通常通过在LocalContainerEntityManagerFactoryBean的特殊属性指定为”jpaProperties”。在使用Hibernate的情况下,这些属性甚至是需要基于特定的版本的;请查阅Hibernate文档以获取详细信息。
  • Spring的HibernateJpaVendorAdapter会强制执行某些面向Spring的默认设置,例如在Hibernate 5.0中匹配Hibernate自己的默认值的连接释放模式“on-close”,但在5.1 / 5.2中不再存在。对于JTA设置,不要声明HibernateJpaVendorAdapter开始,或关闭其prepareConnection标志。或者,将Hibernate 5.2的hibernate.connection.handling_mode属性设置为DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT以恢复Hibernate自己的默认值。有关WebLogic的相关说明,请参考Hibernate的虚假应用服务器警告一节。
  • 或者,可以考虑从应用程序服务器本身获取EntityManagerFactory,即通过JNDI查找而不是本地声明的LocalContainerEntityManagerFactoryBean。服务器提供的EntityManagerFactory可能需要在服务器配置中进行特殊定义,减少了部署的移植性,但是EntityManagerFactory将为开箱即用的服务器JTA环境设置。