Interpretation der Verwendung von Spring @Transactional Annotation

Überblick

Das Transaktionsmanagement ist für Unternehmensanwendungen von entscheidender Bedeutung und kann auch dann sicherstellen, dass Datenkonsistenz auftreten.

Spring Framework bietet eine konsistente Abstraktion für das Transaktionsmanagement mit seinen Eigenschaften wie folgt:

Stellen Sie konsistente Programmiermodelle für verschiedene Transaktions -APIs wie JTA (Java Transaction API), JDBC, Hibernate, JPA (Java Persistence API und JDO (Java -Datenobjekte) bereit

Unterstützt ein deklaratives Transaktionsmanagement, insbesondere ein deklaratives Transaktionsmanagement auf der Grundlage von Anmerkungen, die einfach und einfach zu bedienen sind

Bietet eine einfachere API für Programmiertransaktionsmanagement als andere Transaktions -APIs wie JTA

Perfekte Integration mit Springdatenzugriffsabstraktion

Transaktionsverwaltungsmethode

Spring unterstützt zwei Methoden: programmatisches Transaktionsmanagement und deklaratives Transaktionsmanagement.

Das programmatische Transaktionsmanagement verwendet TransactionTemplate oder verwendet direkt den zugrunde liegenden PlatformTransactionManager. Für die programmatische Transaktionsführung empfiehlt Spring die Verwendung von TransactionTemplate.

Das deklarative Transaktionsmanagement basiert auf AOP. Seine Essenz besteht darin, die Methode vor und nach und nachher abzufangen und dann eine Transaktion zu erstellen oder hinzuzufügen, bevor die Zielmethode beginnt. Nach der Ausführung der Zielmethode wird die Transaktion gemäß der Ausführungssituation eingereicht oder zurückgerollt. Der größte Vorteil von deklarativen Transaktionen besteht darin, dass sie nicht programmgesteuert Transaktionen verwalten müssen, sodass im Geschäftslogikcode kein Dotieren von Transaktionsmanagementcode dotiert werden muss. Führen Sie einfach relevante Transaktionsregeln Deklarationen in der Konfigurationsdatei (oder über @transactional Annotation) vor und Sie können Transaktionsregeln auf die Geschäftslogik anwenden.

Offensichtlich ist das deklarative Transaktionsmanagement besser als das programmatische Transaktionsmanagement, was genau die nicht-invasive Entwicklungsmethode ist, die vom Frühjahr befürwortet wird. Das deklarative Transaktionsmanagement hält die Geschäftsordnung frei von Kontaminationen. Ein normales Pojo -Objekt kann eine vollständige Transaktionsunterstützung durch Hinzufügen von Anmerkungen erhalten. Im Vergleich zu Programmiertransaktionen besteht der einzige Nachteil von deklarativen Transaktionen darin, dass die feinste Granularität des letzteren nur auf Methodenebene wirken kann und nicht als programmatische Transaktion auf der Codeblockebene wirken kann. Trotz einer solchen Anforderung gibt es jedoch viele Problemumgehungen, z.

Es gibt auch zwei häufig verwendete Methoden zum deklarativen Transaktionsmanagement. Eine ist die XML -Konfigurationsdatei basierend auf den TX- und AOP -Namespaces, und der andere basiert auf der @Transactional -Annotation. Offensichtlich ist die mit Annotations basierende Methode einfacher und einfacher zu bedienen und erfrischender.

Automatisches Commit (AutoCommit) und ob automatisch einreichen, wenn die Verbindung geschlossen ist

Automatikübermittlung

Standardmäßig befindet sich die Datenbank im automatischen Einreichungsmodus. Jede Anweisung befindet sich in einer separaten Transaktion. Wenn die Ausführung dieser Erklärung abgeschlossen ist und die Ausführung erfolgreich ist, wird die Transaktion implizit eingereicht.

Wenn die Ausführung fehlschlägt, wird die Transaktion implizit zurückgerollt.

Für das normale Transaktionsmanagement befindet sich eine Reihe von zugehörigen Vorgängen in einer Transaktion, sodass der automatische Komitee -Modus der Datenbank ausgeschaltet werden muss. Wir müssen uns jedoch keine Sorgen machen. Spring wird die automatische Komitee -Funktion der zugrunde liegenden Verbindung zu False festlegen.

org/springframework/jdbc/dataSource/dataSourcetransactionManager.java

 // Bei Bedarf zum manuellen Commit wechseln. Dies ist bei einigen JDBC -Treibern sehr teuer, //, daher möchten wir es nicht unnötig tun (zum Beispiel, wenn wir den Verbindungspool explizit konfiguriert haben, um ihn bereits festzulegen) .if (con.getAutocommit ()) {txObject.setMustRestoreAtocommit (true); if (logger.isdebugenabled ()) {logger.debug ("JDBC Connection [" + con + "] in manuelles Commit"); } con.setAutocommit (false);}

Einige Datenverbindungspools bieten Einstellungen zum Ausschalten der automatischen Transaktions -Commits, die beim Einrichten des Verbindungspools am besten ausgeschaltet werden können. C3P0 bietet diese Funktion jedoch nicht und kann sich nur darauf verlassen, dass die Feder sie einstellen.

Da die JDBC -Spezifikation feststellt, dass das Verbindungsobjekt bei der Festlegung des automatischen Komitsmodus der Standardwert über den DBMS ist und das automatische Commit bei Bedarf explizit ausgeschaltet werden muss. C3P0 bleibt diese Spezifikation und ermöglicht es dem Client -Code, den erforderlichen Einreichungsmodus explizit festzulegen.

Ob automatisch einreichen, wenn die Verbindung geschlossen ist

Was sollte mit einer nicht verbindlichen Transaktion behandelt werden, wenn eine Verbindung geschlossen wird? In der JDBC -Spezifikation wird nicht erwähnt, dass die Standardrichtlinie von C3P0 darin besteht, nicht übereinstimmende Transaktionen zurückzurollen. Dies ist die richtige Strategie, aber es gibt keine Einigung zwischen JDBC -Treiberanbietern in dieser Frage.

Die automatische Eigenschaft von C3P0 ist standardmäßig falsch, sodass sie nicht verschoben werden müssen. Oder Sie können diese Eigenschaft explizit auf false setzen, was klarer sein wird.

Annotationsbasierte deklarative Transaktionsmanagementkonfiguration

Spring-Service.xml

 <!-Transaktionsunterstützung-> <!-PlatformTransactionMnager-> <bean id = "txManager"> <Eigenschaft name = "dataSource" ref = "dataSource" /> < /bean> <!-Aktivierung der Transaktionsannotationsunterstützung-> <Tx: Annotation-gesteuerte Transaktionsmanager = "TXMANGE" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />" /> " />

Fügen Sie auch den TX-Namespace in feder-servlet.xml hinzu

 ... xmlns: tx = "http://www.springframework.org/schema/tx" xmlns: aop = "http://www.spingframework.org/schema/aop" xsi: Schemalocation = "... http :/wwwwwwwwwwww./wwwww.Schema/- http://www.springframework.org/schema/tx/spring-tx.xsd ...

MyBatis nimmt automatisch ohne zusätzliche Konfiguration am Spring Transaction Management teil. Solange die von org.mybatis.spring.SQLSessionFactoryBean verwiesene Datenquelle mit der von DataSourcetRansactionManager verwiesenen Datenquelle übereinstimmt, funktioniert das Transaktionsmanagement ansonsten nicht.

Darüber hinaus müssen Sie das Abhängigkeitspaket Aopalliance.jar herunterladen und in das Web-inf/lib-Verzeichnis einfügen. Andernfalls wird eine Ausnahme gemeldet, wenn die Frühling initialisiert wird

java.lang.noclassDeffoundError: org/aopalliance/intercept/methodInterceptor

Federtransaktionsmerkmale

Alle Richtlinienklassen des Transaktionsmanagements im Frühjahr werden von org.springframework.transaction.PlatformTransactionManager -Schnittstelle vererbt

 public interface platformTransactionManager {transactionStatus getTransaction (TransactionDefinition Definition) löst TransactionException aus; void Commit (TransactionStatus Status) löst TransactionException aus; void Rollback (TransactionStatus -Status) löst TransactionException aus;}

Die TransactionDefinition -Schnittstelle definiert die folgenden Eigenschaften:

Transaktions -Isolationsstufe

Das Isolationsniveau bezieht sich auf den Grad der Isolation zwischen mehreren gleichzeitigen Transaktionen. Fünf Konstanten, die Isolationsniveaus darstellen, sind in der Transaktionsdefinition Grenzfläche definiert:

TransactionDefinition.isolation_default: Dies ist der Standardwert, der die Standard -Isolationsstufe angibt, die für die zugrunde liegende Datenbank verwendet wird. Für die meisten Datenbanken ist dieser Wert in der Regel transaktionsdefinition.isolation_read_committ.

TransactionDefinition.isolation_Read_uncommitt: Diese Isolationsstufe zeigt an, dass eine Transaktion Daten lesen kann, die durch eine andere Transaktion modifiziert wurden, aber noch nicht begangen wurden. Dieses Level verhindert nicht schmutziges Lesen, sich wiederholendes Lesen und Phantom -Lesen, so dass diese Isolationsstufe selten verwendet wird. Zum Beispiel hat PostgreSQL diese Ebene eigentlich nicht.

TransactionDefinition.isolation_read_Commidt: Diese Isolationsstufe bedeutet, dass eine Transaktion nur Daten lesen kann, die von einer anderen Transaktion begangen wurden. Dieses Level verhindert schmutziges Lesen, was in den meisten Fällen auch der empfohlene Wert ist.

TransactionDefinition.isolation_repeatable_read: Diese Isolationsstufe zeigt an, dass eine Transaktion eine Abfrage während des gesamten Prozesses mehrmals ausführen kann und die zurückgegebenen Datensätze jedes Mal gleich sind. Dieses Level verhindert schmutzige und nicht wiederholbare Lesungen.

TransactionDefinition.isolation_Serializable: Alle Transaktionen werden nacheinander nacheinander ausgeführt, so dass es keine Möglichkeit einer Störung zwischen den Transaktionen gibt, dh diese Ebene kann schmutziges Lesen, nicht wiederholbares Lesen und Phantom-Lesen verhindern. Dies wird jedoch die Leistung des Programms ernsthaft beeinflussen. Dieses Level wird normalerweise nicht verwendet.

Transaktionskommunikationsverhalten

Das sogenannte Transaktionsausbreitungsverhalten bezieht sich darauf, dass es mehrere Optionen gibt, die das Ausführungsverhalten einer Transaktionsmethode angeben können, wenn bereits vor Beginn der aktuellen Transaktion ein Transaktionskontext vorhanden ist. Die Definition der Transaktiondefinition enthält die folgenden Konstanten, die das Verhalten des Ausbreitungsverhaltens darstellen:

TransactionDefinition.Propagation_Required: Wenn derzeit eine Transaktion vorhanden ist, verbinden Sie die Transaktion. Wenn derzeit keine Transaktion vorliegt, erstellen Sie eine neue Transaktion. Dies ist der Standardwert.

TransactionDefinition.Propagation_requires_new: Erstellt eine neue Transaktion, und wenn die Transaktion derzeit vorhanden ist, wird die aktuelle Transaktion ausgesetzt.

TransactionDefinition.Propagation_Supports: Schließen Sie sich der Transaktion bei, wenn derzeit eine Transaktion vorliegt. Wenn es derzeit keine Transaktion gibt, wird es weiterhin nicht transaktional ausgeführt.

TransactionDefinition.Propagation_not_Supported: Läuft nicht übertransaktional, und wenn derzeit eine Transaktion besteht, wird die aktuelle Transaktion ausgesetzt.

TransactionDefinition.Propagation_Never: Läuft auf nicht-transaktionale Weise eine Ausnahme, wenn derzeit eine Transaktion vorhanden ist.

TransactionDefinition.Propagation_Mandatory: Schließen Sie sich der Transaktion bei, wenn derzeit eine Transaktion vorliegt. Wenn derzeit keine Transaktion vorliegt, wird eine Ausnahme ausgelöst.

TransactionDefinition.Propagation_nested: Wenn derzeit eine Transaktion vorhanden ist, wird eine Transaktion erstellt, um als verschachtelte Transaktion der aktuellen Transaktion auszuführen. Wenn es keine Transaktion gibt, entspricht der Wert der Transaktionsdefinition.Propagation_Required.

Transaktionszeitüberschreitung

Das sogenannte Transaktionszeitlimit bezieht sich auf die maximale Zeit, die durch eine Transaktion zulässig ist. Wenn die Frist überschritten wird, die Transaktion jedoch nicht abgeschlossen wurde, wird die Transaktion automatisch zurückgerollt. Bei der Transaktiondefinition wird das Timeout durch den Wert von INT dargestellt und seine Einheit beträgt Sekunden.

Die Standardeinstellung ist der Zeitüberschreitungswert des zugrunde liegenden Transaktionssystems. Wenn das zugrunde liegende Datenbank -Transaktionssystem den Zeitüberschreitungswert nicht festlegt, ist es keine und es gibt keine Zeitüberschreitungsgrenze.

Transaktionsschreibende Attribute

Transaktionen nur schreibgeschützte Transaktionen werden in Situationen verwendet, in denen der Client-Code nur schreibgeschützt ist, aber keine Daten ändert. Transaktionen nur schreibgeschützte Transaktionen werden in bestimmten Szenarien zur Optimierung verwendet, beispielsweise bei der Verwendung von Hibernate.

Der Standardwert wird Transaktionen gelesen und schreiben.

Rollback -Regeln für Frühlingstransaktion

Die empfohlene Möglichkeit, den Spring Transaction Manager zu unterweisen, eine Transaktion zurückzuwirken, besteht darin, eine Ausnahme im Kontext der aktuellen Transaktion zu machen. Der Spring Transaction Manager fängt unberechtigte Ausnahmen auf und entscheidet dann, ob die Transaktion zurückrollt, die die Ausnahme basierend auf den Regeln ausführt.

Standardmäßig wird Spring nur die Transaktion zurückrollen, wenn die ausgeworfene Ausnahme eine nicht überprüfte Ausnahme von Laufzeit ist, dh die geworfene Ausnahme ist eine Unterklasse von RunTimeException (Fehler verursachen auch Transaktionsrollback), während das Auswerfen einer überprüften Ausnahme keine Transaktionsrollback verursacht.

Es ist möglich, die Transaktion explizit so zu konfigurieren, dass diese Ausnahmen abgeworfen werden, einschließlich überprüfter Ausnahmen. Es ist auch möglich, diese Transaktionen eindeutig zu definieren, die nicht zurückrollen, wenn Ausnahmen geworfen werden.

Sie können auch die Methode setRollbackonly () programmgesteuert verwenden, um anzuzeigen, dass eine Transaktion zurückgerollt werden muss. Das einzige, was Sie nach dem Aufrufen von setRollbackonly () tun können, ist Rollback.

@Transactional Annotation

@Transactional Eigenschaften

Verwendung

@Transactional kann auf Schnittstellen, Schnittstellenmethoden, Klassen und Klassenmethoden wirken. Wenn Sie auf eine Klasse reagieren, haben alle öffentlichen Methoden der Klasse Transaktionseigenschaften dieser Art. Gleichzeitig können wir diese Annotation auch auf Methodenebene verwenden, um die Definition auf Klassenebene zu überschreiben.

Obwohl die @Transactional-Annotation auf Schnittstellen, Schnittstellenmethoden, Klassen und Klassenmethoden angewendet werden kann, empfiehlt Spring, diese Annotation nicht für Schnittstellen oder Schnittstellenmethoden zu verwenden, da dies nur bei der Verwendung eines interface-basierten Proxy wirksam wird. Darüber hinaus sollte die @Transactional -Annotation nur auf die öffentliche Methode angewendet werden, die durch die Art der Frühlings -AOP bestimmt wird. Wenn Sie die @Transactional -Annotation für geschützte, private oder Standard -Sichtbarkeitsmethoden verwenden, wird dies ignoriert und keine Ausnahmen werden geworfen.

Standardmäßig werden nur Methodenaufrufe von außen vom AOP -Proxy erfasst. Wenn Sie andere Methoden innerhalb dieser Klasse innerhalb der Klasse aufrufen, wird kein Transaktionsverhalten verursacht, selbst wenn die aufgerufene Methode unter Verwendung der @Transactional -Annotation geändert wird.

 @Transactional (readonly = true) public class defaultFoService implementiert FooService {public foo getfoo (String Fooname) {// etwas tun} // Diese Einstellungen haben Vorrang für diese Methode. updatefoo (foo foo) {// etwas tun}}

Zusammenfassen

Das obige ist der gesamte Inhalt der Interpretation der Verwendung von @Transactional Annotation im Frühjahr durch diesen Artikel, und ich hoffe, dass es für alle hilfreich sein wird. 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!