Primavera de datos JPA

La especificación Spring JPA, disponible en el paquete org.springframework.orm.jpa, proporciona soporte integral Java Persistence API es similar a la integración con Hibernate, al tiempo que permite una implementación básica para proporcionar funcionalidad adicional.

Tres opciones para configurar JPA en un Entorno Spring

El soporte JPA de Spring proporciona tres formas de configurar EntityManagerFactory desde JPA, que es utilizado por la aplicación para obtener el administrador de entidades.

• Usando LocalEntityManagerFactoryBean

• Obteniendo EntityManagerFactory de JNDI

• Usando LocalContainerEntityManagerFactoryBean

Usando LocalEntityManagerFactoryBean

Esto La opción solo se puede utilizar en entornos de implementación simples, como aplicaciones independientes y pruebas de integración.

LocalEntityManagerFactoryBean crea un EntityManagerFactory adecuado para entornos de implementación simples donde la aplicación utiliza sólo JPA para acceder a los datos. La fábrica de beans utiliza un mecanismo para determinar automáticamente el PersistenceProvider de JPA (según el arranque de JPA en Java SE) y en la mayoría de los casos solo requiere que se especifique el nombre de la unidad de persistencia. En el siguiente ejemplo XML, se configura el siguiente bean:

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

Esta forma de implementación JPA es la más simple y la más limitada. No puede hacer referencia a una definición de bean DataSource existente desde JDBC y no hay soporte para transacciones globales. Además, el enlace (conversión de código de bytes) de clases persistentes es específico del proveedor y, a menudo, es necesario especificar un agente JVM específico al inicio. Esta opción solo será suficiente para aplicaciones independientes y entornos de prueba para los cuales está diseñada la especificación JPA.

Obtener EntityManagerFactory desde JNDI

Esta opción se puede usar al implementar en un servidor Java EE. Consulte la documentación de su servidor para aprender cómo implementar un proveedor JPA personalizado en su servidor, lo que le permitirá utilizar un proveedor distinto del proveedor predeterminado del servidor.

Obtener EntityManagerFactory de JNDI (por ejemplo, en el entorno Java EE) es cuestión de cambiar la configuración XML, como se muestra en el siguiente ejemplo:

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

Esta acción supone el arranque estándar de Java EE. El servidor Java EE detecta automáticamente unidades de persistencia (esencialmente archivos META-INF/persistence.xml en archivos jar de la aplicación) y entradas persistence-unit-ref en el descriptor de implementación de Java EE. (por ejemplo, web.xml) y define la ubicación del contexto de nomenclatura del entorno para estas unidades de persistencia.

En tal escenario, la implementación de unidades de persistencia, incluido el enlace (código de bytes) transformación) del almacenamiento de clases persistentes es enteramente responsabilidad del servidor Java EE. El DataSource de JDBC se define a través de la ubicación JNDI en el archivo META-INF/persistence.xml. Las transacciones de EntityManager son una parte integral del subsistema JTA del servidor. Spring simplemente usa el EntityManagerFactory resultante, pasándolo a los objetos de la aplicación mediante inyección de dependencia y administrando transacciones para la unidad de persistencia (normalmente a través de un JtaTransactionManager).

Si en una sola aplicación se utilizan varias unidades de persistencia, los nombres de los beans de esas unidades de persistencia recuperadas de JNDI deben coincidir con los nombres de las unidades de persistencia que la aplicación utiliza para referirse a ellas (por ejemplo, en @PersistenceUnit y anotaciones @PersistenceContext).

Uso de LocalContainerEntityManagerFactoryBean

Esta opción se puede utilizar para utilizar completamente las instalaciones JPA en un Entorno de aplicaciones basado en Spring. Esto incluye contenedores web como Tomcat, aplicaciones independientes y pruebas de integración con requisitos de persistencia complejos.

LocalContainerEntityManagerFactoryBean brinda control total sobre la configuración de EntityManagerFactory y es adecuado para entornos donde se requiere un ajuste fino. LocalContainerEntityManagerFactoryBean crea una instancia de PersistenceUnitInfo basada en el archivo persistence.xml proporcionado por la estrategia dataSourceLookup y especificado por loadTimeWeaver. De esta manera, puede trabajar con fuentes de datos personalizadas fuera de JNDI y gestionar el proceso de enlace. El siguiente ejemplo muestra una definición de bean típica para un LocalContainerEntityManagerFactoryBean:

<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>

El siguiente ejemplo muestra un archivo persistence.xml típico:

<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>

Usar LocalContainerEntityManagerFactoryBean es la configuración JPA más eficiente opción, proporcionando una configuración local flexible en la aplicación. Admite referencias a DataSource existente de JDBC, admite transacciones locales y globales, etc. Sin embargo, también impone requisitos en el entorno de ejecución, como tener un cargador de clases enlazable si el proveedor de persistencia requiere conversión de código de bytes.

Esta opción puede entrar en conflicto con las instalaciones JPA nativas del servidor Java EE. En un entorno Java EE completo, considere obtener EntityManagerFactory de JNDI. Alternativamente, defina una persistenceXmlLocation personalizada en la definición LocalContainerEntityManagerFactoryBean (por ejemplo, META-INF/my-persistence.xml) e incluya solo un identificador con ese nombre en el archivo jar de su aplicación archivos. Dado que el servidor Java EE solo busca archivos META-INF/persistence.xml estándar, ignora dichas unidades de persistencia personalizadas, evitando así conflictos con la configuración JPA basada en Spring. (Esto se aplica, por ejemplo, a Resin 3.1).

La interfaz LoadTimeWeaver es una clase contenida en Spring que le permite conectar instancias ClassTransformer desde JPA de una manera específica, dependiendo del ya sea que el entorno sea un contenedor web o un servidor de aplicaciones. Conexión de ClassTransformers a través de agente suele ser ineficaz. Los agentes se ejecutan en toda la máquina virtual y verifican cada clase que se carga, lo que generalmente no es deseable en un entorno de servidor de producción.

Spring contiene varias implementaciones de LoadTimeWeaver para diferentes entornos, lo que permite instancias de a utilizar ClassTransformer es solo por cargador de clases, no por máquina virtual.

Más información sobre las implementaciones de LoadTimeWeaver y su configuración, tanto escritas como adaptadas a diferentes plataformas (como Tomcat, JBoss y WebSphere), consulte la sección sobre configuración Spring en el capítulo AOP.

Como se describe en la sección sobre Configuración de Spring, puede configurar LoadTimeWeaver para todo el contexto usando la anotación @EnableLoadTimeWeaving o el context:load-time-weaver de elementos XML. Esta herramienta de enlace global es recogida automáticamente por todas las instancias LocalContainerEntityManagerFactoryBean de JPA. El siguiente ejemplo muestra la forma preferida de configurar el enlazador en el momento del arranque para detectar automáticamente la plataforma (como el cargador de clases habilitado para enlazador de Tomcat o el agente JVM de Spring) y propagar automáticamente el enlazador a todos los beans que lo admiten:

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

Sin embargo, si es necesario, puede configurar manualmente la herramienta de enlace dedicada a través de loadTimeWeaver propiedad, como se muestra en el siguiente ejemplo:

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

Independientemente de cómo esté configurado el enlace de tiempo de carga (LTW), con esta técnica las aplicaciones JPA que dependen de instrumentación pueden ejecutarse en el plataforma de destino (por ejemplo, Tomcat) sin necesidad de un agente. Esto es especialmente importante si las aplicaciones host utilizan diferentes implementaciones JPA, ya que los solucionadores JPA se aplican solo en el nivel de clase del cargador y, por lo tanto, están aislados entre sí.

Trabajar con múltiples unidades de persistencia

Para aplicaciones que utilizan múltiples ubicaciones de unidades de persistencia (almacenadas, por ejemplo, en diferentes archivos JAR en el classpath), Spring ofrece un PersistenceUnitManager que actúa como un repositorio central y evita el proceso de descubrimiento de unidades de persistencia, que puede ser costoso. La implementación predeterminada permite especificar múltiples ubicaciones. Estas ubicaciones se analizan y posteriormente se recuperan mediante el nombre de la unidad de persistencia. (De forma predeterminada, el classpath busca archivos META-INF/persistence.xml). El siguiente ejemplo tiene varias ubicaciones configuradas:

<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 the data source is not specified, use this -->
    <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>

La implementación predeterminada permite configurar instancias PersistenceUnitInfo (antes de pasarlas al proveedor JPA) o de forma declarativa (a través de sus propiedades que afectan a todas las unidades alojadas) o mediante programación (a través de PersistenceUnitPostProcessor, que permite el muestreo de unidades de persistencia). Si PersistenceUnitManager no está configurado, se creará y utilizará dentro de LocalContainerEntityManagerFactoryBean.

Antecedentes bootstrap

LocalContainerEntityManagerFactoryBean admite la funcionalidad de arranque en segundo plano a través de la propiedad bootstrapExecutor, como se muestra en el siguiente ejemplo:

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="bootstrapExecutor">
        <bean class="org.springframework.core.task.SimpleAsyncTaskExecutor"/>
    </property>
</bean>

El programa de arranque del proveedor JPA real se pasa al trabajador especificado y luego, en paralelo, al subproceso de arranque de la aplicación. El proxy público EntityManagerFactory se puede inyectar en otros componentes de la aplicación e incluso es capaz de responder a las comprobaciones de configuración de EntityManagerFactoryInfo. Sin embargo, si otros componentes acceden al proveedor JPA real (por ejemplo, llamando a createEntityManager), esas llamadas se bloquean hasta que se completa el arranque en segundo plano. En particular, si está utilizando Spring Data JPA, asegúrese de configurar también el arranque diferido para sus repositorios.

Implementación de DAO basada en JPA: EntityManagerFactory y EntityManager

Es posible escribir código en JPA simple sin dependencias de Spring usando el EntityManagerFactory inyectado o EntityManager. Spring puede reconocer las anotaciones @PersistenceUnit y @PersistenceContext tanto a nivel de campo como de método si PersistenceAnnotationBeanPostProcessor está habilitado. El siguiente ejemplo muestra una implementación típica de JPA DAO utilizando la anotación @PersistenceUnit:

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();
            }
        }
    }
}

class ProductDaoImpl : ProductDao {
    private lateinit var emf: EntityManagerFactory
    @PersistenceUnit
    fun setEntityManagerFactory(emf: EntityManagerFactory) {
        this.emf = emf
    }
    fun loadProductsByCategory(category: String): Collection<*> {
        val em = this.emf.createEntityManager()
        val query = em.createQuery("from Product as p where p.category = ?1");
        query.setParameter(1, category);
        return query.resultList;
    }
}

El DAO predecesor es independiente de Spring y todavía encaja bien en el contexto de la aplicación Spring. Además, el DAO aprovecha las anotaciones para solicitar la implementación de un EntityManagerFactory estándar, como se muestra en la siguiente definición de bean de ejemplo:

<beans>
    <!-- posprocesador de beans para anotaciones JPA -->
    <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
    <bean id="myProductDao" class="product.ProductDaoImpl"/>
</beans>

Como alternativa a definir explícitamente PersistenceAnnotationBeanPostProcessor, considere usar el elemento XML context:annotation-config de Spring en la configuración del contexto de la aplicación. De esta manera, todos los postprocesadores estándar de Spring para la configuración basada en anotaciones, incluido CommonAnnotationBeanPostProcessor, etc., se registrarán automáticamente.

Considere el siguiente ejemplo:

<beans>
    <!-- postprocesadores para todas las anotaciones de configuración estándar -->
    <context:annotation-config/>
    <bean id="myProductDao" class="product.ProductDaoImpl"/>
</beans>

El principal problema con un DAO de este tipo es que siempre crea un nuevo EntityManager a través de una fábrica. Puede evitar esto solicitando que se inyecte un EntityManager transaccional (también llamado "EntityManager genérico" porque es un proxy genérico y seguro para subprocesos para el EntityManager transaccional real) en lugar de la fábrica. El siguiente ejemplo muestra cómo hacer esto:

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();
    }
}

class ProductDaoImpl : ProductDao {
    @PersistenceContext
    private lateinit var em: EntityManager
    fun loadProductsByCategory(category: String): Collection<*> {
        val query = em.createQuery("from Product as p where p.category = :category")
        query.setParameter("category", category)
        return query.resultList
    }
}

La anotación @PersistenceContext tiene un atributo opcional type, cuyo valor predeterminado es PersistenceContextType.TRANSACTION. Puede utilizar este valor predeterminado para obtener un proxy EntityManager compartido. La alternativa, concretamente PersistenceContextType.EXTENDED, es un asunto completamente diferente. El resultado es el llamado EntityManager extendido, que no es seguro para subprocesos y, por lo tanto, no debe usarse en un bean que esté expuesto a acceso concurrente, como un bean singleton administrado por Spring. Las instancias del EntityManager extendido están destinadas a ser utilizadas exclusivamente por beans con estado, como los contenidos en una sesión, y el ciclo de vida del EntityManager no está vinculado a la transacción actual. , pero depende completamente de las aplicaciones.

El EntityManager inyectado es administrado por Spring (tiene en cuenta la transacción actual). Incluso si la nueva implementación DAO utiliza la inyección a nivel de método EntityManager en lugar de EntityManagerFactory, no se requieren cambios en el contexto XML de la aplicación debido al uso de anotaciones.

La principal ventaja de este estilo DAO es que solo depende de la API de persistencia de Java. No es necesario importar ninguna clase Spring. Además, dado que se reconocen las anotaciones JPA, el contenedor Spring aplica automáticamente la inyección. Esto es atractivo desde una perspectiva no invasiva y puede resultar más natural para los desarrolladores de JPA.

Transacciones JPA administradas por Spring

La estrategia recomendada para JPA son las transacciones locales utilizando el soporte de transacciones integrado de JPA. JpaTransactionManager de Spring ofrece muchas de las características familiares de las transacciones locales JDBC (como niveles de aislamiento específicos de transacciones y optimizaciones de solo lectura a nivel de recursos) frente a cualquier grupo de conexiones JDBC normal (sin requisitos XA).

JPA a través de Spring también permite que un JpaTransactionManager configurado abra una transacción JPA para un código de acceso JDBC que accede al mismo DataSource, siempre que el registrado JpaDialect admite la recuperación de la Connection subyacente de JDBC. Spring contiene dialectos para implementaciones de EclipseLink e Hibernate a través de JPA.

Introducción a JpaDialect y JpaVendorAdapter

Como una característica extendida de JpaTransactionManager y subclases de AbstractEntityManagerFactoryBean le permite pasar un JpaDialect personalizado a la propiedad del bean jpaDialect. Una implementación de JpaDialect puede incluir las siguientes características avanzadas admitidas por Spring, generalmente dependiendo del proveedor:

• Usar semántica de transacción específica (por ejemplo, nivel de aislamiento personalizado o transacciones de tiempo de espera)

• Obtenga una Connection transaccional JDBC (para abrirla a DAO basados en JDBC)

• Conversión avanzada de PersistenceExceptions a DataAccessExceptions desde Spring

Esto es especialmente útil en el caso de semántica de transacciones y para transformaciones de excepciones avanzadas. La implementación predeterminada de (DefaultJpaDialect) no proporciona ninguna funcionalidad especial y, si se requiere la funcionalidad enumerada anteriormente, se debe especificar el dialecto apropiado.

Consulte: javadoc por JpaDialect y JpaVendorAdapter para obtener más información sobre cómo funcionan y cómo se utilizan dentro del soporte Spring JPA.

Configuración de JPA con JTA Gestión de transacciones

Como alternativa a JpaTransactionManager, Spring también le permite coordinar transacciones con múltiples recursos a través de JTA, ya sea en un entorno Java EE o utilizando un coordinador de transacciones independiente, como Atomikos. Además de elegir JtaTransactionManager en lugar de JpaTransactionManager, hay algunos pasos más que debes seguir:

• El JDBC subyacente Los grupos de conexiones deben ser compatibles con XA y estar integrados con su coordinador de transacciones. Normalmente, en un entorno Java EE, esto se hace simplemente abriendo un DataSource de un tipo diferente a través de JNDI. Consulte la documentación del servidor de aplicaciones para obtener más detalles. Del mismo modo, un coordinador de transacciones independiente normalmente viene con opciones DataSource especializadas integradas con XA. Nuevamente, consulte la documentación.

• La configuración EntityManagerFactory de JPA debe configurarse para JTA. Todo depende del fabricante, pero normalmente esto se hace a través de propiedades especiales, que deben establecerse como jpaProperties para LocalContainerEntityManagerFactoryBean. En el caso de Hibernate, estas propiedades dependen incluso de la versión. Consulte la documentación de Hibernate para obtener más detalles.

• HibernateJpaVendorAdapter de Spring aplica ciertos valores predeterminados específicos de Spring, como el modo de liberación de conexión, on-close, que es el mismo que el valor predeterminado de Hibernate en Hibernate 5.0, pero ya no es el mismo en Hibernate 5.1+. Para configurar JTA, asegúrese de que el tipo de transacción de su unidad de persistencia esté declarado como "JTA". Alternativamente, establezca la propiedad hibernate.connection.handling_mode de Hibernate 5.2 en DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT para restaurar el valor predeterminado de Hibernate. Para obtener notas relacionadas, consulte "Advertencias falsas del servidor de aplicaciones al utilizar Hibernate".

• Como alternativa, considere obtener EntityManagerFactory del propio servidor de aplicaciones (es decir, mediante una búsqueda JNDI en lugar de una declarada localmente). LocalContainerEntityManagerFactoryBean ). El EntityManagerFactory proporcionado por el servidor puede requerir definiciones especiales en la configuración de su servidor (lo que hace que la implementación sea menos independiente de la plataforma), pero está optimizado para el entorno JTA del servidor.

Configuración nativa de Hibernate y transacciones nativas de Hibernate para interoperabilidad con JPA

La configuración nativa LocalSessionFactoryBean combinada con HibernateTransactionManager permite interoperabilidad con anotaciones @PersistenceContext y otros códigos de acceso JPA. SessionFactory de Hibernate ahora implementa de forma nativa la interfaz EntityManagerFactory de JPA, y el identificador Session de Hibernate ahora es el EntityManager de JPA de forma nativa. El soporte JPA de Spring define automáticamente las sesiones nativas de Hibernate.

Por lo tanto, esta configuración nativa de Hibernate puede servir como reemplazo de la combinación estándar LocalContainerEntityManagerFactoryBean y JpaTransactionManager de JPA en muchos escenarios, permitiéndole interactuar con SessionFactory.getCurrentSession() (así como con HibernateTemplate) junto con la anotación @PersistenceContext EntityManager dentro de un único transacción local. Esta configuración también permite una integración más estrecha con Hibernate y una mayor flexibilidad de configuración, ya que no está limitada por los contratos de plantilla de arranque JPA.

En este caso, la configuración de HibernateJpaVendorAdapter no es necesaria porque Spring tiene configuración incorporada Hibernate proporciona aún más funcionalidad (como la configuración personalizada de Hibernate Integrator, la integración del contenedor de beans Hibernate 5.3 y optimizaciones más sólidas para transacciones de solo lectura). Por último, pero no menos importante, también puede expresar la configuración nativa de Hibernate a través de LocalSessionFactoryBuilder, iterando fácilmente la configuración basándose en la anotación @Bean (sin usar FactoryBean).