@Transactional (noRollbackFor=RuntimeException.class) nicht verhindern rollback auf RuntimeException

@Transactional (noRollbackFor=RuntimeException.class)
public void methodA (Entity e){
   service.methodB(e);
}

---service-Methode unten---

@Transactional (propagation=Propagation.REQUIRES_NEW, noRollbackFor=RuntimeException.class)
public void methodB (Entity e){
   dao.insert(e);
}

Wenn dao.insert(e) im methodB() Ursachen einen primären Schlüssel Verstoß und wirft einen ConstraintViolationException, welche eine Unterklasse von RuntimeException würde ich erwarten, dass die Transaktion noch zu verpflichten, weil der noRollbackFor Eigenschaft, die ich verwendet. Aber ich habe beobachtet, dass die äußere Transaktion (auf methodA) ist immer noch rollte wieder durch die HibernateTransactionManager mit der Meldung

org.springframework.die Transaktion.UnexpectedRollback Ausnahme:
Die Transaktion wird rückgängig gemacht, weil es hat gewesen markiert als rollback-nur

Ich gefunden habe, die ähnliche Fragen berichtet, aber nicht genau dieses.

  • Hast du globalRollbackOnParticipationFailure false E. g. <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="globalRollbackOnParticipationFailure" value="false" /> <property name="sessionFactory" ref="sessionFactory" /> </bean>
  • ziemlich sicher sol4me ist auf dem richtigen Weg - siehe stackoverflow.com/a/11205537/1594449
  • Klingt wie eine gute Idee, aber ich bin nicht daran interessiert, ändern Sie die Einstellung von globalRollbackOnParticipationFailure weil ich die Weiterentwicklung eines vorhandenen monolithisches Stück code, der bereits verwendet die gleichen Transaktions-manager, und ich würde wollen, halten Sie den vorhandenen code unberührt durch meine änderung - es scheint nicht möglich, durch ändern der tx-manager config. Kann ich etwas tun, was ganz speziell für meine Veränderung?
  • nur zu deiner information, ich habe auch versucht, fangen die RuntimeException geworfen dao.insert(e); innerhalb methodB und erneutes auslösen von es sich nach dem wickeln es in eine checked exception. Ich habe die noRollbackFor zu entsprechen, die geprüfte Ausnahme verwendet. Allerdings, das machte keinen Unterschied - für die äußere Transaktion in methodA war immer noch rollte zurück!
  • sind methodA und MethodB auf das gleiche Objekt/Dienstleistung?
  • wie wird die Transaktion gestartet/propagiert für methodA, Auch einen Blick auf die Abfragen, die ausgelöst wird, auf der Rückseite, macht method A versucht, etwas einfügen wie auch beim Spülen..??
  • wäre es egal, die startet die Transaktion für methodA seit methodB wird eine neue Transaktion gestartet?
  • ja, es spielt keine Rolle, da methodB startet eigene Transaktion,

InformationsquelleAutor ThermalEagle | 2015-01-08
  1. 12

    Einmal eine Ausnahme abgefangen wird, die Hibernate-Session sollte verworfen werden und die Transaktion sollte zurückgerollt werden:

    Wenn die Sitzung eine Ausnahme auslöst, wird die Transaktion muss zurückgesetzt werden
    zurück-und die Sitzung verworfen. Der interne Status der Sitzung
    vielleicht nicht mit der Datenbank konsistent ist, nachdem die Ausnahme Auftritt.

    So, noRollbackFor für Ihre Service-und DAO-Schicht, die eine Ausnahme auslösen könnte. Lassen Sie uns sagen, Sie haben eine gatewayService, dass schreiben zu einer Datenbank über ein Hibernate-DAO und auch sendet eine E-Mail über eine emailService. Wenn der emailService wirft einen SendMailFailureException Sie können anweisen, die gatewayService nicht zurück zu Rollen, wenn es diese Ausnahme abfangen:

    @Transactional(noRollbackFor=SendMailFailureException.class)
public void saveAndSend(Entity e){
   dao.save(e);
   emailService.send(new Email(e));
}
    • Gut erklärt mit einem Beispiel
    • was mein Verständnis ist - Method B hat seine eigene Transaktion, der Methode Eine Transaktion unterbrochen , so als proxy, proxy nannte es target method method B, und wenn irgendeine Ausnahme Auftritt, für die no rollback konfiguriert ist, nur das Geschäft kümmern, dann wird es wieder die Transaktion von method A
    • Selbst wenn eine neue Transaktion, weil der Vermehrung.REQUIRES_NEW, das gleiche Prinzip gilt für die Hibernate-Session.
    InformationsquelleAutor Vlad Mihalcea
Schreibe einen Kommentar