Transazione contrassegnata solo come rollback: come trovo la causa

Ho problemi con il commit di una transazione con il mio metodo @Transactional:

methodA() {
    methodB()
}

@Transactional
methodB() {
    ...
    em.persist();
    ...
    em.flush();
    log("OK");
}

Quando chiamo methodB () da methodA (), il metodo passa correttamente e posso vedere "OK" nei miei log. Ma poi capisco

Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Transaction marked as rollbackOnly org.springframework.transaction.TransactionSystemException: Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Transaction marked as rollbackOnly
    at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:521)
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754)
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:393)
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:120)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:622)
    at methodA()...

1. Il contesto del metodoB è completamente mancante nell'eccezione - che va bene suppongo?
2. Qualcosa all'interno del metodoB () ha contrassegnato la transazione solo come rollback? Come posso scoprirlo? Ad esempio, esiste un modo per verificare qualcosa del genere getCurrentTransaction().isRollbackOnly()?: in questo modo, potrei seguire il metodo e trovare la causa.

Quando contrassegni il tuo metodo come @Transactional, il verificarsi di qualsiasi eccezione all'interno del tuo metodo segnerà il TX circostante solo come rollback (anche se li prendi). Puoi utilizzare altri attributi di @Transactionalannotazione per evitare che si ripristini come:

@Transactional(rollbackFor=MyException.class, noRollbackFor=MyException2.class)

Finalmente ho capito il problema:

methodA() {
    methodB()
}

@Transactional(noRollbackFor = Exception.class)
methodB() {
    ...
    try {
        methodC()
    } catch (...) {...}
    log("OK");
}

@Transactional
methodC() {
    throw new ...();
}

Quello che succede è che anche se methodBha l'annotazione giusta, methodCnon lo fa. Quando viene generata l'eccezione, la seconda @Transactionalcontrassegna comunque la prima transazione solo come Rollback.

Per recuperare rapidamente l'eccezione che causa senza la necessità di ricodificare o ricostruire , impostare un punto di interruzione su

org.hibernate.ejb.TransactionImpl.setRollbackOnly() // Hibernate < 4.3, or
org.hibernate.jpa.internal.TransactionImpl() // as of Hibernate 4.3

e sali nella pila, di solito da qualche Interceptor. Lì puoi leggere l'eccezione che causa da qualche blocco catch.

Ho lottato con questa eccezione durante l'esecuzione della mia applicazione.

Infine il problema riguardava la query sql . voglio dire che la query è sbagliata.

verifica la tua richiesta. Questo è il mio suggerimento

Cerca le eccezioni che vengono lanciate e catturate nelle ...sezioni del tuo codice. Le eccezioni dell'applicazione di runtime e di rollback causano il rollback quando vengono espulse da un metodo aziendale anche se catturate da qualche altra parte.

È possibile utilizzare il contesto per scoprire se la transazione è contrassegnata per il rollback.

@Resource
private SessionContext context;

context.getRollbackOnly();

Ho trovato una buona spiegazione con le soluzioni: https://vcfvct.wordpress.com/2016/12/15/spring-nested-transactional-rollback-only/

1) rimuovere @Transacional dal metodo annidato se non richiede realmente il controllo delle transazioni. Quindi anche se ha un'eccezione, si limita a bolle e non influisce sulle cose transazionali.

O:

2) se il metodo annidato necessita del controllo delle transazioni, impostalo come REQUIRE_NEW per la politica di propagazione in questo modo anche se genera un'eccezione e contrassegnato solo come rollback, il chiamante non verrà influenzato.

disabilita il transactionmanager nel tuo file Bean.xml

<tx:annotation-driven proxy-target-class="true" transaction-manager="transactionManager"/>
    <bean id="transactionManager"
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource"></property>
    </bean>

commentate queste righe e vedrete l'eccezione che causa il rollback;)

applica il codice seguente in productRepository

@Query("update Product set prodName=:name where prodId=:id ") @Transactional @Modifying int updateMyData(@Param("name")String name, @Param("id") Integer id);

mentre nel test junit applicare sotto il codice

@Test
public void updateData()
{
  int i=productRepository.updateMyData("Iphone",102);

  System.out.println("successfully updated ... ");
  assertTrue(i!=0);

}

funziona bene per il mio codice