2011-06-22 24 views
8

Me gustaría entender el uso de tener una transacción de primavera con soportes de propagación. Los documentos Java mencionan que si el método que tiene @Transactional(propagation = Propagation.SUPPORTS) se llama desde dentro de una transacción, admite la transacción, pero si no existe ninguna transacción, el método se ejecuta de forma no transaccional.Transacciones de muelles con propagación de apoyos

¿No es este el comportamiento de las transacciones de primavera independientemente de Propagation.SUPPORTS?

 


public class ServiceBean { 

    @Transactional(propagation = Propagation.SUPPORTS) 
    public void methodWithSupportsTx() { 
     //perform some database operations 
    } 
} 

public class OtherServiceBean { 

    @Transactional(propagation = Propagation.REQUIRED) 
    public void methodWithRequiredTx() { 
     //perform some database operations 
     serviceBean.methodWithSupportsTx(); 
    } 
} 

 

En el ejemplo de código anterior, con independencia de si tiene methodWithSupportsTx()@Transactional(propagation = Propagation.SUPPORTS) anotación que sería ejecutado en una transacción en función de si tiene methodWithRequiredTx()@Transactional anotación, ¿verdad?

¿Cuál es la necesidad/uso de tener un nivel de propagación SOPORTES?

Respuesta

0

Una transacción requerida creará una nueva transacción si no existe. Por lo tanto, se realizaría una nueva transacción cuando llame a serviceBean.methodWithSupportsTx(). Si su método es verdaderamente transaccional, verá un error desde la primavera si no existe ninguna transacción.

+0

No lo creo. Se produce un error solo cuando el nivel de propagación es NUNCA. También PROPAGATION.SUPPORTS no crea una nueva transacción. –

4

De javadoc:

Nota: Para administradores de transacciones con la sincronización transacción, PROPAGATION_SUPPORTS es ligeramente diferente de ninguna transacción en absoluto, ya que define un ámbito de transacción que la sincronización se aplicará para. Como consecuencia, los mismos recursos (conexión JDBC, sesión de Hibernate, etc.) se compartirán para todo el alcance especificado. Tenga en cuenta que esto depende de la configuración de sincronización real del administrador de transacciones.

Por lo tanto, esto significa que, por ejemplo, múltiples invocaciones de hibernación de SessionFactory.getCurrentSession() dentro methodWithSupportsTx() volverían la misma sesión.

+0

Suponiendo que methodWithSupportsTx() no tiene una anotación @Transactional ¿está tratando de decir que la misma sesión NO se devolverá cuando se llame a methodWithSupportsTx() en una transacción? –

+0

@Amit: en realidad, sin el intento '@ Transactional' de llamar a' getCurrentSession() 'con la configuración típica de' HibernateTransactionManager' produciría una sesión "No Hibernate enlazada a thread, y la configuración no permite la creación de una no transaccional aquí" excepción. – axtavt

+0

No, quiero decir, si no hay anotaciones @Transactional en el método methodWithSupportsTx() y este método se llama desde otro método que ya está en una transacción, no hibernate devolverá la misma sesión al hacer varias invocaciones de SessionFactory.getCurrentSession de Hibernate(). Este es exactamente el ejemplo que afirmo en mi pregunta anterior: la anotación @Transactional en methodWithRequiredTx() crea una nueva transacción y luego llama a serviceBean.methodWithSupportsTx(), por lo tanto, el código ejecutado por methodWithSupportsTx() ya estaría en una transacción, ¿verdad? –

Cuestiones relacionadas