In letzter Zeit habe ich an einem Projekt gearbeitet und versehentlich festgestellt, dass eine Klasse die Dinge rollback operiert und die Daten normalerweise in die Datenbank eingefügt wurden.
Alles beginnt immer noch mit den überprüften Ausnahmen von Java und nicht überprüften Ausnahmen.
Was ist also eine Ausnahme vom Typ Inspektionstyp und was ist eine Ausnahme vom Typ Nichtspektionstyp?
Es gibt zwei einfachste Urteilspunkte:
1. Die nicht passende Ausnahme, die von RunTimeException oder Irrtum geerbt wurde, während die von Ausnahme geerbte Überprüfungsausnahme (natürlich RunTimeException selbst ist auch eine Unterklasse ausnahmslos).
2. Nicht überprüfte Ausnahmen können gefangen werden, ohne gefangen zu werden, während überprüfte Ausnahmen mit Versuch bearbeitet werden müssen ... Catch-Anweisungsblock oder die Ausnahme von der überlegenen Verarbeitungsmethode übergeben werden. Kurz gesagt, Code muss geschrieben werden, um ihn zu verarbeiten.
Die Ausnahmestruktur von Java ist in der folgenden Abbildung dargestellt. Unter ihnen müssen Ausnahmen, die die Ausnahme direkt erben, erwischt und überprüft werden.
Schauen wir zurück auf meinen Code:
1. Dem Methodnamen geht es vor von
@Transactional
2. Spring Configuration Datei ApplicationContext-XXX.xml hat auch verwandte Konfigurationen für Spring-Dinge.
<bean id = "transactionManager"> <Eigenschaft name = "dataSource" ref = "dataSource"/> <Eigenschaft name = "rollbackoncommitfailure" value = "true"> </property> </bean>
Aber warum wird das, was nach dem Versuch eingereicht wurde ... Exception Exception Exception, wird nicht zurückgerollt, wenn die Service -Layer -Methode aufgerufen wird?
Nachdem ich die relevante Frühlingsdokumentation überprüft hatte, stellte ich fest, dass die ursprüngliche Deklarative Transaktionsverwaltung von Spring-Deklarative Transaktionen standardmäßig bei nicht überprüften Ausnahmen und Laufzeitausnahmen durchführte, während keine Rollbacks bei überprüften Ausnahmen.
Die Ausnahme, die durch Versuch ausgelöst wird ... Fang im Code ist eine Ausnahme von Check -Typ. Das Framework von Spring rollt standardmäßig nicht zurück.
Bei der Programmierung können nicht überprüfte Ausnahmen vermieden werden, während überprüfte Ausnahmen mit Versuchsanweisungsblöcken verarbeitet oder an die überlegene Methode übergeben werden, um sie zu verarbeiten. Kurz gesagt, Code muss geschrieben werden, um sie zu verarbeiten.
Daher muss die Ausnahme im Dienst gefangen werden und dann eine nicht überprüfte Ausnahme manuell wieder auswerfen, damit die Transaktion wirksam wird. Zum Beispiel:
try{ ……… } catch (Exception e) { ……… throw new BusinessException(e.getMessage()); }Natürlich haben wir eine einfachere Möglichkeit, dieses Problem zu lösen, dh die Standard -Rollback -Methode durch Annotieren von Parametern zu ändern.
Norollbackfor und Rollbackfor sind in der @Transaction -Annotation definiert, um anzugeben, ob eine bestimmte Ausnahme zurückgerollt wird.
Beispiele verwenden:
@Transaction (norollbackfor = runTimeException.class)
@Transaction (Rollbackfor = Exception.class)
In der obigen Frage können Sie daher den Rollback -Parameter @Transaction (Rollbackfor = Exception.class) direkt hinzufügen, der die Standard -Transaktionsverarbeitungsmethode ändert.
Offenbarung:
Dies erfordert, dass wir die benutzerdefinierte Ausnahme von RunTimeException bei der Anpassung der Ausnahme erben, damit sie bei der Standard -Transaktionsverarbeitung von Spring genau behandelt wird.
Zusammenfassen
Das obige ist der gesamte Inhalt dieses Artikels über das Problem des Fehlers der Java -Transaktionsrollback. Ich hoffe, es wird für alle hilfreich sein. Interessierte Freunde können weiterhin auf andere verwandte Themen auf dieser Website verweisen. Wenn es Mängel gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen. Vielen Dank an Freunde für Ihre Unterstützung für diese Seite!