java - mediante - spring mvc 4 tutorial español

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, diferentes bases de datos) configurados en una aplicación personalizada de middleware de Spring.

Quiero usar 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 al hacer esto cuando hay varios administradores de transacciones, a pesar de que el archivo de contexto está configurado correctamente (las referencias van a la unidad de persistencia correcta. ¿Alguien alguna vez ha visto un problema?

En tu configuración, ¿tendrías dos administradores de transacciones? ¿Tendrían txManager1 y txManager2?

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

Answer 1

Supongo que tienes 2 opciones

Si sus casos de uso nunca requieren actualizaciones para 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, necesitaría recurrir al mecanismo anterior de usar un simple TransactionProxyFactoryBean para definir los límites de la 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 necesita una transacción que abarque ambas bases de datos, necesitará usar un administrador de transacciones JTA. La API dice:

Este administrador de transacciones es apropiado para 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, utilizamos una 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 se está implementando dentro de un servidor de aplicaciones, entonces el Spring JtaTransactionManager necesita realizar una búsqueda del administrador de transacciones JTA real compatible con XA proporcionado 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 soy tan familiar. ¿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.

Espero que esto ayude

Answer 2

La única situación en la que puede tener dos administradores de transacciones de Spring es si nunca tiene ambas transacciones abiertas a la vez. 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 usan el TransactionSynchronizationManager de Spring, que mantiene un montón de estado crítico en las variables estáticas de ThreadLocal, por lo que los gerentes de transacción tienen la garantía de pisotear el estado de cada uno.