Transaction marquée comme annulation uniquement: comment trouver la cause

Je rencontre des problèmes pour valider une transaction dans ma méthode @Transactional:

methodA() {
    methodB()
}

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

Quand j'appelle methodB () depuis methodA (), la méthode passe avec succès et je peux voir "OK" dans mes journaux. Mais alors je reçois

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. Le contexte de methodB est complètement absent de l'exception - ce qui est bien je suppose?
2. Quelque chose dans la méthodeB () a marqué la transaction comme une annulation uniquement? Comment puis-je le découvrir? Existe-t-il, par exemple, un moyen de vérifier quelque chose comme getCurrentTransaction().isRollbackOnly()?- comme ça, je pourrais parcourir la méthode et trouver la cause.

Lorsque vous marquez votre méthode comme @Transactional, l'occurrence d'une exception à l'intérieur de votre méthode marquera le TX environnant comme un retour arrière uniquement (même si vous les attrapez). Vous pouvez utiliser d'autres attributs d' @Transactionalannotation pour l'empêcher de revenir en arrière comme:

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

J'ai enfin compris le problème:

methodA() {
    methodB()
}

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

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

Ce qui se passe, c'est que même si le methodBa la bonne annotation, le methodCne le fait pas. Lorsque l'exception est levée, la seconde @Transactionalmarque la première transaction comme Rollback uniquement de toute façon.

Pour récupérer rapidement l'exception à l'origine sans avoir besoin de recoder ou de reconstruire , définissez un point d'arrêt sur

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

et montez dans la pile, généralement vers un intercepteur. Là, vous pouvez lire l'exception à l'origine de certains blocs catch.

J'ai eu du mal avec cette exception lors de l'exécution de mon application.

Enfin, le problème était sur la requête SQL . je veux dire que la requête est fausse.

veuillez vérifier votre requête. C'est ma suggestion

Recherchez les exceptions levées et interceptées dans les ...sections de votre code. Les exceptions d'application d'exécution et de restauration provoquent une restauration lorsqu'elles sont rejetées d'une méthode métier, même si elles sont interceptées à un autre endroit.

Vous pouvez utiliser le contexte pour savoir si la transaction est marquée pour une annulation.

@Resource
private SessionContext context;

context.getRollbackOnly();

J'ai trouvé une bonne explication avec des solutions: https://vcfvct.wordpress.com/2016/12/15/spring-nested-transactional-rollback-only/

1) supprimez @Transacional de la méthode imbriquée si elle ne nécessite pas vraiment de contrôle de transaction. Donc, même s'il a une exception, cela ne fait que bouillonner et n'affecte pas les choses transactionnelles.

OU:

2) si la méthode imbriquée nécessite un contrôle de transaction, définissez-la comme REQUIRE_NEW pour la politique de propagation de cette façon, même si elle lance une exception et est marquée uniquement comme une annulation, l'appelant ne sera pas affecté.

désactiver le gestionnaire de transaction dans votre 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>

commentez ces lignes, et vous verrez l'exception provoquant l'annulation;)

appliquer le code ci-dessous dans productRepository

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

tandis que dans le test junit, appliquer ci-dessous le code

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

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

}

cela fonctionne bien pour mon code