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
deJNDI
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.
LocalSessionFactoryBean
nativo de Hibernate en lugar del
LocalContainerEntityManagerFactoryBean
normal de JPA, permitiéndole interactuar con el código de acceso
JPA así como con el código de acceso nativo de Hibernate. . Para obtener más información, consulte "Configuración
nativa de Hibernate para la interoperabilidad con JPA".
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>
<exclude-unlisted-classes/>
indica que las
clases de entidad anotadas no deben escanearse. Un valor explícito de "verdadero" (<exclude-unlisted-classes>true</exclude-unlisted-classes/>
)
también significa que no hay verificación. <exclude-unlisted-classes>false</exclude-unlisted-classes/>
provoca una verificación. Sin embargo, recomendamos omitir el elemento exclude-unlisted-classes
si
desea escanear clases de entidad.
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
EntityManagerFactory
son seguras para
subprocesos, las instancias EntityManager
no lo son. Un EntityManager
integrado de JPA
se comporta como un EntityManager
derivado del entorno JNDI del servidor de aplicaciones, tal como
lo define la especificación JPA. Delega todas las llamadas al EntityManager
transaccional actual,
si lo hay. De lo contrario, recurre a un EntityManager
recién creado para cada operación, lo que
efectivamente hace que su uso sea seguro para subprocesos.
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.
HibernateTransactionManager
nativo de Spring es capaz de interactuando con el código de acceso JPA, adaptándose a algunas de las
características de Hibernate y proporcionando interoperabilidad con JDBC. Esto tiene especial sentido en
combinación con la configuración LocalSessionFactoryBean
. Para obtener más información, consulte "Configuración
nativa de Hibernate para interoperabilidad con 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
aDataAccessExceptions
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.
JpaVendorAdapter
, una herramienta de adaptación de proveedores aún más amplia principalmente para
personalizar completamente LocalContainerEntityManagerFactoryBean
de Spring, combina las capacidades de
JpaDialect
con otras Las opciones específicas del proveedor son las predeterminadas. Configurar HibernateJpaVendorAdapter
o EclipseLinkJpaVendorAdapter
es la forma más conveniente de configurar automáticamente EntityManagerFactory
para Hibernate o EclipseLink, respectivamente. Tenga en cuenta que estos adaptadores de proveedor están destinados
principalmente para su uso con la gestión de transacciones basada en Spring (es decir, para su uso con JpaTransactionManager
).
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 opcionesDataSource
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 comojpaProperties
paraLocalContainerEntityManagerFactoryBean
. 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 propiedadhibernate.connection.handling_mode
de Hibernate 5.2 enDELAYED_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
). ElEntityManagerFactory
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
).
LocalSessionFactoryBean
y
LocalSessionFactoryBuilder
admiten el arranque en segundo plano, como
LocalContainerEntityManagerFactoryBean
de JPA. Para obtener información introductoria, consulte "Arranque
en segundo plano".
Para un LocalSessionFactoryBean
, esto está disponible a través de la
propiedad bootstrapExecutor
. En un software LocalSessionFactoryBuilder
, el método
sobrecargado buildSessionFactory
toma una carga inicial del argumento del ejecutor.