Tief verstehen das Transaktionsausbreitungsverhalten von Spring zutiefst

Vorwort

Spring Gibt 7 Arten von Transaktionsausbreitungsverhalten in der Transaktionsfinition -Schnittstelle an. Transaktionsausbreitungsverhalten ist eine Transaktionsverbesserungsfunktion, die für das Spring -Framework einzigartig ist, und gehört nicht zum Datenbankverhalten des tatsächlichen Anbieters der Transaktion. Dies ist eine leistungsstarke Toolbox, die Spring uns bietet, und die Verwendung von Transaktionsausbreitungsleitungen kann viele Annehmlichkeiten für unsere Entwicklungsbemühungen bieten. Aber die Leute haben viele Missverständnisse darüber, und Sie müssen das Gerücht gehört haben, dass "das Service -Methode -Geschäft am besten nicht verschachtelt ist". Um Tools korrekt zu verwenden, müssen Sie zuerst die Tools verstehen. In diesem Artikel werden das Verhalten der sieben Transaktionsausbreitung im Detail vorgestellt und die Hauptcode -Beispiele des Inhalts vorgestellt.

Grundkonzepte

1. Was ist Transaktionskommunikationsverhalten?

Das Transaktionsausbreitungsverhalten wird verwendet, um zu beschreiben, wie Transaktionen ausbreitet werden, wenn Methoden, die durch ein bestimmtes Transaktionsausbreitverhalten modifiziert sind, in eine andere Methode verschachtelt werden.

Verwenden Sie Pseudo-Code, um zu erklären:

 public void methoda () {methodb (); // dosomething} @transaction (Propagation = xxx) public void methodb () {// dosomething}

methodA() -Methode im Code ruft methodB() -Methode in verschachteltem und das Transaktionsausbreitungsverhalten von methodB() durch @Transaction(Propagation=XXX) bestimmt. Es ist hier zu beachten, dass methodA() die Transaktion nicht startet und die Methode zur Änderung eines bestimmten Transaktionsausbreitungsverhaltens in der peripheren Methode zur Start der Transaktion nicht aufgerufen werden muss.

2. Verhaltensweisen der Transaktionsausbreitung im Frühjahr

Die Definition ist sehr einfach und leicht zu verstehen. Gehen wir zum Abschnitt mit dem Code -Test, um zu überprüfen, ob unser Verständnis korrekt ist.

Codeüberprüfung

Der Code in diesem Artikel wird in zwei Ebenen in einer traditionellen Dreischichtstruktur, nämlich der Dienst und der DAO-Ebene, dargestellt. Spring ist für die Abhängigkeitsinjektions- und Annotation -Transaktionsmanagement verantwortlich. Die DAO -Schicht wird von MyBatis implementiert. Sie können auch jede bevorzugte Methode wie Hibernate, JPA, JDBCTEMplate usw. verwenden

Zuerst erstellen wir zwei Tabellen in der Datenbank:

Benutzer1

 Tabelle `user1` (` id` Integer Unsigned nicht null auto_increment, `name` varchar (45) nicht null Standard ', Primärschlüssel (` id`)) Engine = InnoDB;

Benutzer2

 Tabelle `user2` (` id` Integer Unsigned nicht null auto_increment, `name` varchar (45) nicht null Standard ', Primärschlüssel (` id`)) Engine = InnoDB;

Schreiben Sie dann den entsprechenden Code für Bean- und DAO -Schicht:

Benutzer1

 public class user1 {private Integer id; privater Zeichenfolge Name; // Methoden erhalten und festlegen werden weggelassen ...}

Benutzer2

 public class user2 {private Integer id; privater Zeichenfolge Name; // Methoden erhalten und festlegen werden weggelassen ...}

User1Mapper

 public interface user1Mapper {int insert (user1 -Datensatz); User1 selectByprimaryKey (Ganzzahl -ID); // andere Methoden werden weggelassen ...}

User2Mapper

 public interface user2Mapper {int insert (user2 -Datensatz); User2 selectByprimaryKey (Ganzzahl -ID); // andere Methoden werden weggelassen ...}

Schließlich wird der spezifische Verifizierungscode von der Serviceschicht implementiert, und wir werden ihn in den folgenden Situationen auflisten.

1.Propagation_Required

Wir fügen den entsprechenden Methoden von User1Service und User2Service Propagation.REQUIRED hinzu.

User1Service -Methode:

 @ServicePublic Class User1ServiceImpl implementiert user1Service {// andere ... @Override @Transactional (Propagation = Propagation.required) public void addRequired (user1 user) {user1Mapper.insert (Benutzer); }}

User2Service -Methode:

 @ServicePublic Class User2ServiceImpl implementiert user2Service {// andere ... @Override @Transactional (Propagation = Propagation.required) public void addRequired (user2 user) {user2Mapper.insert (Benutzer); } @Override @transactional (Propagation = Propagation.Required) public void addRequiredException (user2 user) {user2Mapper.insert (Benutzer); neue runimeexception () werfen; }}

1.1 Szene 1

Diese periphere Methode Szenario aktiviert keine Transaktionen.

Überprüfungsmethode 1:

 @Override public void Nottransaction_exception_required_required () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addRequired (user2); neue runimeexception () werfen; }

Überprüfungsmethode 2:

 @Override public void Nottransaction_required_required_exception () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addRequiredException (user2); }

Verifikationsmethoden separat ausführen und die Ergebnisse:

Analyse der Ergebnisse der Seriennummer Datenbank der Verifizierungsmethode

Schlussfolgerung: Durch diese beiden Methoden beweisen wir, dass die durch Ausbreitung modifizierte interne Methode ihre eigenen Transaktionen neu öffnet, wenn die periphere Methode die Transaktion nicht öffnet, und die geöffneten Transaktionen sind unabhängig voneinander und stören sich nicht miteinander.

1.2 Szene 2

Die periphere Methode startet die Transaktion, bei der es sich um ein Szenario mit einer relativ hohen Nutzungsrate handelt.

Überprüfungsmethode 1:

 @Override @Transactional (Propagation = Propagation.Required) public void transaction_exception_required_required () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addRequired (user2); neue runimeexception () werfen; }

Überprüfungsmethode 2:

 @Override @Transactional (Propagation = Propagation.Required) public void transaction_required_required_exception () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addRequiredException (user2); }

Überprüfungsmethode 3:

 @Transactional @Override public void transaction_required_required_exception_try () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); try {user2Service.addRequiredException (user2); } catch (Ausnahme e) {System.out.println ("Methode Rollback"); }}

Verifikationsmethoden separat ausführen und die Ergebnisse:

Schlussfolgerung: Die obigen experimentellen Ergebnisse zeigen, dass bei der öffnenden peripheren Methode die durch Propagation.REQUIRED modifizierte interne Methoden zur Transaktion der peripheren Methode hinzugefügt werden. Alle internen Methoden und peripheren Methoden, die durch Propagation.REQUIRED modifiziert wurden. Erforderne Methoden gehören zur gleichen Transaktion. Solange eine Methode zurückrollt, wird die gesamte Transaktion zurückgerollt.

2.Propagation_requires_new

Wir fügen das Attribut von Propagation.REQUIRES_NEW zu den entsprechenden Methoden von User1Service und User2Service hinzu.

User1Service -Methode:

 @ServicePublic Class user1ServiceImpl implementiert user1Service {// andere ... @Override @Transactional (Propagation = Propagation.Requires_New) public void addRequiresNew (Benutzer1 -Benutzer) {user1mapper.insert (Benutzer); } @Override @Transactional (Propagation = Propagation.Required) public void addRequired (user1 user) {user1Mapper.insert (Benutzer); }}

User2Service -Methode:

 @ServicePublic Class User2ServiceImpl implementiert user2Service {// andere ... @Override @Transactional (Propagation = Propagation.Requires_New) public void addRequiresNew (Benutzer2 -Benutzer) {user2Mapper.insert (Benutzer); } @Override @transactional (Propagation = Propagation.Requires_New) public void addRequiresNewException (user2 user) {user2Mapper.insert (Benutzer); neue runimeexception () werfen; }}

2.1 Szene 1

Die periphere Methode aktiviert keine Transaktionen.

Überprüfungsmethode 1:

 @Override public void Nottransaction_exception_requiresnew_requiresnew () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addrequiresNew (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addrequiresNew (user2); neue runimeexception () werfen; }

Überprüfungsmethode 2:

 @Override public void Nottransaction_requiresnew_requiresnew_exception () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addrequiresNew (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addrequiresNewException (user2); }

Verifikationsmethoden separat ausführen und die Ergebnisse:

Schlussfolgerung: Durch diese beiden Methoden beweisen wir, dass die durch Propagation.REQUIRES_NEW modifizierte interne Methode ihre eigenen Transaktionen neu starten und die geöffneten Transaktionen voneinander unabhängig sind und sich nicht miteinander stören.

2.2 Szene 2

Die periphere Methode startet die Transaktion.

Überprüfungsmethode 1:

 @Override @Transactional (Propagation = Propagation.required) public void transaction_exception_required_requiresnew_requiresNew () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addrequiresNew (user2); User2 user3 = new user2 (); user3.setName ("wang wu"); user2Service.addrequiresNew (user3); neue runimeexception () werfen; }

Überprüfungsmethode 2:

 @Override @Transactional (Propagation = Propagation.required) public void transaction_required_requiresnew_requiresnew_exception () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addrequiresNew (user2); User2 user3 = new user2 (); user3.setName ("wang wu"); user2Service.addRequiresNewException (user3); }

Überprüfungsmethode 3:

 @Override @Transactional (Propagation = Propagation.required) public void transaction_required_requiresnew_requiresnew_exception_try () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addRequired (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addrequiresNew (user2); User2 user3 = new user2 (); user3.setName ("wang wu"); try {user2Service.addrequiresNewException (user3); } catch (Ausnahme e) {System.out.println ("Rollingback"); }}

Verifikationsmethoden separat ausführen und die Ergebnisse:

Schlussfolgerung: Wenn die periphere Methode die Transaktion öffnet, öffnet die interne Methode, die durch Propagation.REQUIRES_NEW modifiziert wurde. Erquire_New öffnet immer noch unabhängige Transaktionen separat und ist auch unabhängig von den externen Methodentransaktionen. Die internen Methode, die interne Methode und die externen Methodentransaktionen sind unabhängig voneinander und stören sich nicht gegenseitig.

3.Propagation_Nested

Wir fügen den entsprechenden Methoden von User1Service und User2Service Propagation.NESTED Attribute hinzu.

User1Service -Methode:

 @ServicePublic Class User1ServiceImpl implementiert user1Service {// andere ... @Override @Transactional (Propagation = Propagation.Nested) public void addnested (user1 user) {user1mapper.insert (user); }}

User2Service -Methode:

 @ServicePublic Class User2ServiceImpl implementiert user2Service {// andere ... @Override @Transactional (Propagation = Propagation.Nested) public void addnested (user2 user) {user2Mapper.insert (Benutzer); } @Override @Transactional (Propagation = Propagation.Nested) public void addnestedException (user2 user) {user2Mapper.insert (Benutzer); neue runimeexception () werfen; }}

3.1 Szene 1

Diese periphere Methode Szenario aktiviert keine Transaktionen.

Überprüfungsmethode 1:

 @Override public void Nottransaction_exception_nested_nested () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addnested (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addnested (user2); neue runimeexception () werfen; }

Überprüfungsmethode 2:

 @Override public void Nottransaction_nested_nested_exception () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addnested (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addnestedException (user2); }

Verifikationsmethoden separat ausführen und die Ergebnisse:

Schlussfolgerung: Durch diese beiden Methoden beweisen wir, dass Propagation.NESTED und Propagation.REQUIRED ausbreitet und die gleiche Funktionen haben, wenn die periphere Methode die Transaktion nicht öffnet. Die modifizierten internen Methoden starten ihre eigenen Transaktionen erneut, und die geöffneten Transaktionen sind unabhängig voneinander und stören sich nicht miteinander.

3.2 Szene 2

Die periphere Methode startet die Transaktion.

Überprüfungsmethode 1:

 @Transactional @Override public void transaction_exception_nested_nested () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addnested (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addnested (user2); neue runimeexception () werfen; }

Überprüfungsmethode 2:

 @Transactional @Override public void transaction_nested_nested_exception () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addnested (user1); User2 user2 = new user2 (); user2.setName ("li si"); user2Service.addnestedException (user2); }

Überprüfungsmethode 3:

 @Transactional @Override public void transaction_nested_nested_exception_try () {user1 user1 = new user1 (); user1.setName ("Zhang san"); user1Service.addnested (user1); User2 user2 = new user2 (); user2.setName ("li si"); try {user2Service.addnestedException (user2); } catch (Ausnahme e) {System.out.println ("Methode Rollback"); }}

Verifikationsmethoden separat ausführen und die Ergebnisse:

Schlussfolgerung: Die obigen Testergebnisse zeigen, dass die interne Methode, die durch Propagation.NESTED modifiziert ist, wenn die periphere Methode die Transaktion öffnet. Nestiert gehört zur Subtransaktion der externen Transaktion. Die periphere Haupttransaktion rollt zurück und die Untertransaktion muss zurückrollen. Die interne Subtransaktion kann separat zurückgeführt werden, ohne die periphere Haupttransaktion und andere Untertransaktionen zu beeinflussen.

V.

Aus dem Vergleich von "1.2 Szene 2" und "3.2 Szene 2" können wir sehen:

Die durch verschachtelten und erforderlichen internen Methoden sind beide periphere Methodentransaktionen. Wenn die periphere Methode eine Ausnahme ausgelöst hat, werden die Transaktionen beider Methoden zurückgerollt. Die erforderlichen Verbindungsverbindungen verbinden jedoch periphere Methodentransaktionen, sodass sie zur gleichen Transaktion wie periphere Transaktionen gehört. Sobald die erforderliche Transaktion eine Ausnahme ausgelöst hat und zurückgerollt wird, werden auch periphere Methodentransaktionen zurückgerollt. Verschachtelt ist eine Untertransaktion der peripheren Methode und hat einen separaten Speicherpunkt, sodass die verschachtelte Methode eine Ausnahme ausgelegt und zurückgeschaltet wird, was die Transaktion der peripheren Methode nicht beeinflusst.

Aus dem Vergleich von "2.2 Szene 2" und "3.2 Szene 2" können wir sehen:

Sowohl verschachtelt als Da verschachtelt ist, ist jedoch eine verschachtelte Transaktion nach dem Rückverstärken der peripheren Methode, die Subtransaktionen, die periphere Methodentransaktionen sind, ebenfalls zurückgerollt. Forderung_New wird durch Öffnen einer neuen Transaktion implementiert. Interne Transaktionen und periphere Transaktionen sind zwei Transaktionen. Die Rollback des peripheren Transaktion beeinflusst die internen Transaktionen nicht.

5. Andere Verhaltensweisen der Transaktionsausbreitung

In Anbetracht des Längenproblems des Artikels werden die Tests anderer Transaktionsausbreitungsverhalten hier nicht beschrieben. Interessierte Leser können nach dem entsprechenden Testcode und Ergebniserklärungen im Quellcode suchen. Portal: https: //github.com/tmtse/tran ...

Simulationswendungsfälle

Wie wenden wir sie nach der Einführung so viele Transaktionskommunikationsverhaltens in unserer tatsächlichen Arbeit an? Lassen Sie mich Ihnen ein Beispiel geben:

Angenommen, wir haben eine registrierte Methode, bei der die Methode zum Hinzufügen von Punkten aufgerufen wird. Wenn wir Punkte hinzufügen möchten, um den Registrierungsprozess nicht zu beeinflussen (dh, kann der Rollback nicht auch die Registrierungsmethode rollen), wir werden Folgendes schreiben:

 @Service public class UserServiceImpl implementiert UserService {@transactional public void Register (Benutzerbenutzer) {try {membershipPointService.AddPoint (Punktpunkt); } catch (Ausnahme e) {// weglassen ...} // weglassen ...} // weglassen ...}

Wir sehen auch fest, dass der Registrierungsfehler addPoint() -Methode (die Registrierungsmethode Rollback erfordert auch Rollback), sodass addPoint() -Methode so implementiert werden muss:

 @Service Public Class MembershipPointServiceImPlements implementiert MITGLIEDSCHAFTPOPPETService {@transactional (Propagation = Propagation.Nested) public void AddPoint (Punktpunkt) {try {recordService.addrecord (Datensatzaufzeichnung); } catch (Ausnahme e) {// weglassen ...} // weglassen ...} // weglassen ...}

Wir haben festgestellt, dass addRecord() addPoint() , das zum Aufzeichnen von Protokollen verwendet wird. Seine Implementierung ist wie folgt:

 @Service Public Class RecordServiceImpl implementiert RecordService {@Transactional (Propagation = Propagation.not_Supported) public void addRecord (Datensatzrekord) {// weggelassen ...} // Oben ...}

Wir haben festgestellt, propagation = Propagation.NOT_SUPPORTED im addRecord() -Methode, da sie nicht genau auf das Protokoll ist und eine mehr oder weniger sein kann, und addRecord() selbst und die periphere addPoint() -Methode veranlasst addRecord() -Methode nicht zu rollen, und addRecord() addPoint() -Methode.

In diesem Beispiel glaube ich, dass jeder ein intuitiveres Verständnis für die Verwendung von Transaktionskommunikationsverhalten hat. Die Kombination verschiedener Attribute kann in der Tat unsere Unternehmensimplementierung flexibler und vielfältiger machen.

abschließend

In der obigen Einführung glaube ich, dass jeder ein tieferes Verständnis für das Verhalten der Frühlingstransaktion hat, und ich hoffe, dass Ihre tägliche Entwicklungsarbeit hilfreich ist.

Zusammenfassen

Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Referenzwert für das Studium oder die Arbeit eines jeden hat. Wenn Sie Fragen haben, können Sie eine Nachricht zur Kommunikation überlassen. Vielen Dank für Ihre Unterstützung bei Wulin.com.