Administradores de transacciones múltiples JPA

Question

Tengo un archivo applicationContext.xml, y tiene dos org.springframework.orm.jpa.JpaTransactionManager (cada uno con su propia unidad de persistencia, bases de datos diferentes) configurados en una aplicación personalizada de middleware Spring.

Quiero utilizar las transacciones basadas en anotaciones (@Transactional), para no perder el tiempo con TransactionStatus commit, save y rollback.

Un compañero de trabajo mencionó que algo se confunde haciendo esto cuando hay varios gestores de transacciones, a pesar de que el archivo de contexto se establece configurado correctamente (las referencias van a la unidad de persistencia correcta. Cualquiera visto alguna vez un problema?

---

En su configuración, usted tiene dos administradores de transacciones? ¿tendría txManager1 y txManager2?

eso es lo que tengo con JPA, dos granos de primavera diferentes que son administradores de transacciones.

Answer 1

Supongo que tiene 2 opciones

Si sus casos de uso nunca requieren actualizaciones en ambas bases de datos dentro de la misma transacción, entonces puede usar dos JpaTransactionManagers, pero no estoy seguro de que pueda usar el enfoque @Transactional ? En este caso, lo que se necesita para el repliegue en el mecanismo anterior de uso de un simple TransactionProxyFactoryBean para definir los límites de transacción, por ejemplo:

<bean id="firstRealService" class="com.acme.FirstServiceImpl"/> 
<bean id="firstService" 
    class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> 
    <property name="transactionManager" ref="firstJpaTm"/> 
    <property name="target" ref="firstRealService"/> 
    <property name="transactionAttributes"> 
     <props> 
      <prop key="insert*">PROPAGATION_REQUIRED</prop> 
      <prop key="update*">PROPAGATION_REQUIRED</prop> 
      <prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 
     </props> 
    </property> 
</bean> 
<!-- similar for your second service --> 

Si está requerir una transacción que abarca ambas bases de datos, entonces usted tendrá que utilizar un JTA gerente de transacciones El API estados:

Este administrador de transacciones es apropiado para las aplicaciones que usan una única JPA EntityManagerFactory para el acceso a datos transaccionales. JTA (generalmente a través de JtaTransactionManager) es necesario para acceder a múltiples recursos transaccionales dentro de la misma transacción. Tenga en cuenta que debe configurar su proveedor de JPA en consecuencia para que participe en las transacciones de JTA.

Lo que esto significa es que deberá proporcionar un administrador de transacciones JTA. En nuestra aplicación, usamos configuración similar a la siguiente:

<tx:annotation-driven transaction-manager="txManager"/> 

<bean id="txManager" 
    class="org.springframework.transaction.jta.JtaTransactionManager"> 
    <property name="transactionManagerName" value="appserver/jndi/path" /> 
</bean> 

Si va a implementar dentro de un servidor de aplicaciones, a continuación, la primavera JtaTransactionManager tiene que hacer una búsqueda con el administrador de transacciones JTA compatible con XA real ofrecida por el servidor de aplicaciones. Sin embargo, también puede usar un administrador de transacciones JTA independiente (pero aún no lo he probado)

En cuanto a la configuración del proveedor de persistencia Jpa, no estoy tan familiarizado. ¿Qué proveedor de persistencia de JPA estás usando?

El código anterior se basa en nuestro enfoque, donde estábamos usando Hibernate nativo en comparación con la implementación de JPA de Hibernate. En este caso, pudimos deshacernos de los dos beans HibernateTransactionManager, y simplemente asegurarnos de que ambos SessionFactories fueron inyectados con el mismo JTA TM, y luego usar el elemento tx: annotation-driven.

Esperanza esto ayuda

Answer 2

La única situación en la que se pueden tener dos administradores de transacciones primavera es si usted nunca tiene tanto las transacciones abiertas al mismo tiempo.Esto no tiene que ver intrínsecamente con las transacciones distribuidas: se aplican las mismas restricciones incluso si desea que los dos orígenes de datos tengan ciclos de vida de transacción completamente separados (pero potencialmente superpuestos en el tiempo).

Internamente todos los gerentes de transacciones de Spring utilizan el TransactionSynchronizationManager de Spring, que mantiene un montón de estado crítico en las variables estáticas de ThreadLocal, por lo que se garantiza que los gestores de transacciones pisotearán el estado de cada uno.