Die Hauptuntersuchung in diesem Artikel ist die Einführung und Beispiele für die Isolationsebene für die Isolation von Spring -Transaktionen wie folgt.
Wenn zwei Transaktionen auf Datensätzen in derselben Datenbank arbeiten, welche Auswirkungen haben sich zwischen ihnen? Dies führt zu dem Konzept der Transaktions -Isolationsstufe. Die Isolation der Datenbank hat viel mit der Kontrolle der Parallelität zu tun. Das Isolationsniveau der Datenbank ist Teil der Säure der Transaktionsmerkmal der Datenbank. Säure, dh Atomizität, Konsistenz, Isolation und Haltbarkeit. Feder hat vier Transaktions -Isolationsstufen: READ_UNCOMMITTED , READ_COMMITTED , REPEATABLE_READ und SERIALIZABLE . Eine andere ist die Standard -Isolationsstufe der DEFAULT , und MySQL standardt zu REPEATABLE_READ .
Schauen wir es uns unten ausführlich an.
Wie der Name schon sagt, bedeutet READ_UNCOMMITTED , dass eine Transaktion Transaktionsdatensätze lesen kann, dass eine andere Transaktion nicht begangen wurde. Mit anderen Worten kann eine Transaktion die Daten lesen, die von anderen Transaktionen noch nicht gewährt werden. Dies ist das schwächste Isolationsniveau für Federtransaktionen. Siehe Abbildung unten, Transaktion A wird eingeschaltet und ein Datensatz geschrieben. Zu diesem Zeitpunkt liest Transaktion B die Daten und liest diesen Datensatz, aber dann rollt Transaktion zurück. Daher ist die durch Transaktion B gelesenen Daten nicht gültig (die Datenbank befindet sich in einem ungültigen Zustand). Diese Situation heißt Dirty Read. Zusätzlich zum schmutzigen Lesungsproblem kann READ_UNCOMMITTED auch non-repeatable read (nicht wiederholendes Lesen) und phantom read (Phantom-Lesen) haben.
Die Isolationsstufe READ_COMMITTED zeigt an, dass eine Transaktion nur die festgelegten Datensätze lesen kann und die nicht übereinstimmenden Datensätze nicht lesen kann. Mit anderen Worten, eine Transaktion kann nur die festgelegten Daten lesen und die nicht verbindlichen Daten nicht lesen. Daher tritt die schmutzige Lesesituation nicht mehr auf, aber andere Probleme können auftreten. Siehe das Bild unten.
Zwischen den beiden Lesevorgängen der Transaktion A modifiziert die Transaktion B diesen Aufzeichnung und begeht sie. Daher sind die vor und nach der Transaktion a gelesenen Datensätze inkonsistent. Dieses Problem wird als nicht wiederholbares Lesen bezeichnet (kann nicht wiederholt gelesen werden). (Die Aufzeichnungen wurden zwischen den zweimal inkonsistent gelesen, und wiederholte Lesungen werden Probleme finden.)
Zusätzlich zu dem nicht wiederholbaren Lesenproblem kann READ_COMMITTED auch Phantom-Leseproblem haben.
Repeatable_Read bedeutet, dass eine Transaktion mehrmals einen Datensatz aus der Datenbank lesen kann und der Datensatz mehrmals gleich ist, dasselbe. Diese Isolationsstufe kann das Problem der schmutzigen Lektüre und der nicht wiederholbaren Lektüre vermeiden, aber das Problem der Phantom-Lesen kann auftreten. Wie in der Abbildung unten gezeigt.
Transaktion A liest zweimal eine Reihe von Datensätzen aus der Datenbank, in der Transaktion B einen Datensatz einfügt und sie einreicht. Bei der Transaktion A liest sich das zweite Mal, dass der Datensatz B gelesen wurde. Während einer Transaktion ist eine Reihe von Datensätzen, die durch Transaktion A zweimal gelesen wurden, inkonsistent, und dieses Problem heißt Phantom Read.
Serialisierbar ist das stärkste Isolationsniveau des Frühlings. Wenn eine Transaktion ausgeführt wird, wird sie auf allen Ebenen gesperrt, z. Dies verhindert schmutziges Lesen, nicht wiederholbares Lesen und Phantom-Lesen, wird jedoch die Leistungsverschlechterung verursachen.
MySQL standardmäßig REPEATABLE_READ .
Schauen wir uns ein Beispiel unten an. Öffnen Sie eine Transaktion in der Datenbank MySQL und begehen Sie nicht. Dann liest eine andere Transaktion den Datensatz.
Zu Beginn sind die Datensätze in der Datenbank wie in der Abbildung gezeigt
Öffnen Sie die Transaktion A in der Datenbank MySQL und fügen Sie einen Datensatz ein.
Das Transaktionsattribut der Dienstklasse im Dienst ist als READ_UNCOMMITTED konfiguriert.
@Transactional (isolation = isolation.read_uncommitt) public class Accountservice {private AccountDao AccountDao; public accountDao getAccountDao () {return contodao;} public void void setAccountDao (AccountDao Accountdao) {thiscoccountdao = accountDao;} void void Transfer (streich, streich, sting, sting, sting, sting, sting, sting, sting, sting, sting, sting, sting, doclountdao = accountdao;} void voiid Transfer (star, sting, sting, sting, von, sting, von, documentdao; accountdao;} void void übertrag (star {accountDao.outmoney (aus, Geld); accountDao.inMoney (an, Geld);} public void readAllUser () {list <Contoes> uscuswends = contoDao.getallUser (); für (Konto Konto: Konten) {System.out.Println (account);Führen Sie die folgende Testklasse aus
Paket com.chris.service; import static org.junit.assert.*; import org.junit.test; import org.junit.runner.runwith; org.springframework.test.context.junit4.SpringJUnit4ClassRunner;@RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration("classpath:applicationContext.xml")public class ReadAllUserTest {@Autowired private AccountService accountService;@Test public void test() {AccountService.readallUser ();}}Die Ergebnisse sind wie folgt:
Es ist ersichtlich, dass diese Transaktion nicht übereinstimmende Daten liest.
Rollen Sie zu diesem Zeitpunkt die in MySQL geöffnete Transaktion zurück.
MySQL> Rollback;
Führen Sie das Programm erneut aus und das Ergebnis ist
Konto [Name = Michael, Money = 1000.0]
Konto [Name = Jane, Money = 1000.0]
Konto [Name = Kate, Money = 1000,0]
Das obige ist der gesamte Inhalt dieses Artikels über die Einführung in die Isolationsebene der Spring -Transaktion und die Analyse von Beispielen. 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!