Detaillierte Einführung in die Spring-Transaktionsprinzipien

1. Grundprinzipien von Transaktionen

Das Wesentliche von Spring-Transaktionen ist eigentlich die Unterstützung von Transaktionen durch die Datenbank. Ohne die Transaktionsunterstützung der Datenbank kann Spring keine Transaktionsfunktionen bereitstellen. Wenn Sie für eine reine JDBC-Betriebsdatenbank Transaktionen verwenden möchten, können Sie die folgenden Schritte ausführen:

1. Verbindung abrufen Connection con = DriverManager.getConnection()

2. Transaktion öffnen con.setAutoCommit(true/false);

3. CRUD ausführen

4. Transaktion festschreiben/Transaktion zurücksetzen con.commit () / con.rollback();

5. Schließen Sie die Verbindung conn.close();

Nachdem wir die Transaktionsverwaltungsfunktion von Spring verwendet haben, haben wir Ich kann dann den Code für die Schritte 2 und 4 nicht schreiben, aber er wird automatisch von Spirng . Wie öffnet und schließt man Transaktionen vor und nach dem von uns geschriebenen CRUD? Um dieses Problem zu lösen, können wir das Implementierungsprinzip des Spring-Transaktionsmanagements als Beispiel kurz vorstellen <.>

1. Konfigurationsdatei

   Aktivieren Sie die AnnotationTreiber und markieren Sie die relevanten Klassen und Methoden mit der @Transactional-Annotation

   Spring analysiert und generiert zu diesem Zeitpunkt verwandte Beans, überprüft die Klassen und Methoden mit relevanten Anmerkungen, generiert Proxys für diese Klassen und Methoden und fügt relevante Konfigurationen gemäß den relevanten Parametern von @Transaction ein , sodass der Agent die relevanten Transaktionen für uns abwickelt (ermöglicht die normale Transaktionsübermittlung und das Ausnahme-Rollback). Die eigentliche Transaktionsübermittlung und das Rollback auf Datenbankebene erfolgt über Binlog oder Redo Log.

2. 2. Spring-Transaktionsausbreitungs-
-Attribut

3. Das sogenannte Ausbreitungsattribut der Spring-Transaktion wird definiert, wenn mehrere Transaktionen gleichzeitig vorhanden sind . Wie Spring mit dem Verhalten dieser Transaktionen umgehen soll, ist in TransactionDefinition definiert. Die Erklärung der spezifischen
-Konstanten

ist in der folgenden Tabelle dargestellt:

Konstantenname	Konstantenerklärung
PROPAGATION_REQUIRED	Unterstützt die aktuelle Transaktion. Wenn keine aktuelle Transaktion vorhanden ist, erstellen Sie eine neue Transaktion . Dies ist die häufigste Wahl und die Standardtransaktionsweitergabe von Spring.
PROPAGATION_REQUIRES_NEW	Neue Transaktion, falls aktuell eine vorhanden ist Transaktion: Unterbricht die aktuelle Transaktion. Die neu erstellte Transaktion hat nichts mit der ausgesetzten Transaktion zu tun. Nachdem die äußere Transaktion fehlgeschlagen ist und zurückgesetzt wurde, können die Ergebnisse der inneren Transaktion nicht zurückgesetzt werden "http://www.php.cn/php/php-tp-throw.html" target="_blank">Wirft eine Ausnahme aus, die von der äußeren Transaktion erfasst wird, oder verarbeitet den Rollback-Vorgang nicht
PROPAGATION_SUPPORTS	Unterstützt die aktuelle Transaktion, wenn derzeit keine Transaktion stattfindet , wird es auf nicht-transaktionale Weise ausgeführt.
PROPAGATION_MANDATORY	Unterstützt die aktuelle Transaktion, wenn keine vorhanden ist Bei der aktuellen Transaktion wird eine Ausnahme ausgelöst.
PROPAGATION_NOT_SUPPORTED	Führen Sie Vorgänge auf nicht-transaktionale Weise aus Wenn derzeit eine Transaktion stattfindet, wird die aktuelle Transaktion ausgesetzt.
PROPAGATION_NEVER	Im nicht-transaktionalen Modus ausführen, wenn Wenn die aktuelle Transaktion vorhanden ist, wird eine Ausnahme ausgelöst.
PROPAGATION_NESTED	Wenn eine aktive Transaktion vorhanden ist, wird sie in einer verschachtelten Transaktion ausgeführt. Wenn keine aktive Transaktion vorhanden ist, wird das REQUIRED-Attribut ausgeführt. Es verwendet eine einzelne Transaktion mit mehreren Sicherungspunkten, die zurückgesetzt werden können. Das Rollback interner Transaktionen hat keine Auswirkungen auf externe Transaktionen. Es funktioniert nur auf dem DataSourceTransactionManager-Transaktionsmanager.

3. Datenbankisolationsstufe

隔离级别	隔离级别的值	导致的问题
Read-Uncommitted	0	导致脏读
Read-Committed	1	避免脏读，允许不可重复读和幻读
Repeatable-Read	2	避免脏读，不可重复读，允许幻读
Serializable	3	串行化读，事务只能一个一个执行，避免了脏读、不可重复读、幻读。执行效率慢，使用时慎重

Dirty Read: Eine Transaktion hat Daten hinzugefügt, gelöscht oder geändert, aber sie wurden nicht festgeschrieben. Eine andere Transaktion kann die nicht festgeschriebenen Daten lesen. Wenn die erste Transaktion zu diesem Zeitpunkt zurückgesetzt wird, liest die zweite Transaktion fehlerhafte Daten.

Nicht wiederholbare Lesevorgänge: In einer Transaktion sind zwei Lesevorgänge aufgetreten. Zu diesem Zeitpunkt wurden die Daten durch eine andere Transaktion geändert.

Phantomlesung: Die erste Transaktion stapelt Änderungen an einem bestimmten Datenbereich, und die zweite Transaktion fügt diesem Bereich Daten hinzu. Zu diesem Zeitpunkt verliert die erste Transaktion die Änderung der neu hinzugefügten Daten .

Zusammenfassung:

Je höher die Isolationsstufe, desto vollständiger und konsistenter können die Daten garantiert werden, aber desto größer ist auch die Auswirkung auf die Parallelitätsleistung.

Die Standardisolationsstufe der meisten Datenbanken ist Read Committed, wie z. B. SqlServer, Oracle

Die Standardisolationsstufe einiger Datenbanken ist: Wiederholbares Lesen, wie zum Beispiel: MySQL InnoDB

4. Isolationsstufe im Frühjahr

常量	解释
ISOLATION_DEFAULT	这是个 PlatfromTransactionManager 默认的隔离级别，使用数据库默认的事务隔离级别。另外四个与 JDBC 的隔离级别相对应。
ISOLATION_READ_UNCOMMITTED	这是事务最低的隔离级别，它充许另外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。
ISOLATION_READ_COMMITTED	保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。
ISOLATION_REPEATABLE_READ	这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
ISOLATION_SERIALIZABLE	这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。

5. Verschachtelung von Transaktionen

Durch das oben genannte theoretische Wissen haben wir ein grobes Verständnis einiger Attribute und Merkmale von Datenbanktransaktionen und Federtransaktionen. Als nächstes analysieren wir einige verschachtelte Transaktionsszenarien Mechanismus der Spring-Transaktionsausbreitung.

Angenommen, dass Methode A() des äußeren Transaktionsdienstes A Methode B() des inneren Dienstes B aufruft

PROPAGATION_REQUIRED (Frühlingsstandard)

Wenn Die Transaktionsebene von ServiceB.methodB() ist als PROPAGATION_REQUIRED definiert, dann hat Spring beim Ausführen von ServiceA.methodA() bereits eine Transaktion gestartet. Zu diesem Zeitpunkt wird ServiceB.methodB() aufgerufen und ServiceB.methodB() erkennt dies läuft bereits in ServiceA. Innerhalb der Transaktion von methodA() wird keine neue Transaktion initiiert.

Wenn ServiceB.methodB() bei der Ausführung feststellt, dass es sich nicht in einer Transaktion befindet, weist es sich selbst eine Transaktion zu.

Auf diese Weise wird die Transaktion zurückgesetzt, wenn irgendwo in ServiceA.methodA() oder ServiceB.methodB() eine Ausnahme auftritt.

PROPAGATION_REQUIRES_NEW

Zum Beispiel entwerfen wir die Transaktionsebene von ServiceA.methodA() auf PROPAGATION_REQUIRED und die Transaktionsebene von ServiceB.methodB() auf PROPAGATION_REQUIRES_NEW .

Wenn dann ServiceB.methodB() ausgeführt wird, wird die Transaktion, in der sich ServiceA.methodA() befindet, angehalten und ServiceB.methodB() startet eine neue Transaktion und wartet auf ServiceB.methodB() Danach Ist die Transaktion abgeschlossen, wird die Ausführung fortgesetzt.

Der Unterschied zwischen PROPAGATION_REQUIRED und PROPAGATION_REQUIRED ist der Grad des Rollbacks der Transaktion. Da ServiceB.methodB() eine neue Transaktion startet, gibt es zwei verschiedene Transaktionen. Wenn ServiceB.methodB() übermittelt wurde, schlägt ServiceA.methodA() fehl und führt ein Rollback durch, ServiceB.methodB() führt jedoch kein Rollback durch. Wenn das Rollback von ServiceB.methodB() fehlschlägt und die von ihm ausgelöste Ausnahme von ServiceA.methodA() abgefangen wird, kann die Transaktion ServiceA.methodA() trotzdem übermittelt werden (dies hängt hauptsächlich davon ab, ob die von B ausgelöste Ausnahme eine Ausnahme ist). Ein Willens-Rollback).

PROPAGATION_SUPPORTS

Angenommen, die Transaktionsebene von ServiceB.methodB() ist PROPAGATION_SUPPORTS. Wenn ServiceB.methodB() ausgeführt wird, wird festgestellt, dass ServiceA. methodA() wurde beim Öffnen einer Transaktion mit der aktuellen Transaktion verbunden. Wenn festgestellt wird, dass ServiceA.methodA() die Transaktion nicht öffnet, wird die Transaktion selbst nicht geöffnet. Zu diesem Zeitpunkt hängt die Transaktionalität der inneren Methode vollständig von der äußersten Transaktion ab.

PROPAGATION_NESTED

Jetzt wird die Situation komplizierter. Das Transaktionsattribut von ServiceB.methodB() ist als PROPAGATION_NESTED konfiguriert ? ServiceB#methodB Bei einem Rollback wird die interne Transaktion (d. h. ServiceB#methodB) auf den SavePoint zurückgesetzt, bevor sie ausgeführt wurde, während die externe Transaktion (d. h. ServiceA#methodA) auf die folgenden zwei Arten verarbeitet werden kann:

a. Ausnahmen erfassen und Ausnahmezweiglogik ausführen

void methodA() { 

        try { 

            ServiceB.methodB(); 

        } catch (SomeException) { 

            // 执行其他业务, 如 ServiceC.methodC(); 

        } 

    }

Diese Methode ist auch der wertvollste Teil verschachtelter Transaktionen. Wenn ServiceB.methodB fehlschlägt, schlägt ServiceC fehl wird ausgeführt. methodC() und ServiceB.methodB wurden vor der Ausführung auf den SavePoint zurückgesetzt, sodass keine schmutzigen Daten generiert werden (entspricht der Tatsache, dass diese Methode nie ausgeführt wird). Diese Funktion kann in einigen speziellen Unternehmen verwendet werden PROPAGATION_REQUIRED Weder PROPAGATION_REQUIRES_NEW noch PROPAGATION_REQUIRES_NEW können dies tun.

b. Der Rollback-/Commit-Code für die externe Transaktion nimmt keine Änderungen vor. Wenn die interne Transaktion (ServiceB#methodB) zurückgesetzt wird, wird zuerst ServiceB.methodB zum SavePoint zurückgesetzt, bevor sie ausgeführt wurde (in jedem Fall). In diesem Fall entscheidet die externe Transaktion (d. h. ServiceA#methodA) entsprechend der spezifischen Konfiguration, ob ein Commit oder ein Rollback durchgeführt wird

Die anderen drei Transaktionsausbreitungsattribute werden grundsätzlich nicht verwendet und werden hier nicht analysiert.

6. Zusammenfassung

Für Orte, an denen Transaktionen im Projekt verwendet werden müssen, empfehle ich Entwicklern, weiterhin die TransactionCallback-Schnittstelle von Spring zu verwenden, um Transaktionen nicht blind zu implementieren Muss verwendet werden. Beachten Sie, dass Sie über ein detailliertes Verständnis des Spring-Transaktionsausbreitungsmechanismus und der Isolationsstufe verfügen müssen, da sonst unerwartete Auswirkungen auftreten können.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in die Spring-Transaktionsprinzipien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!