Sie haben recht:auf der Standard-Isolationsebene
, read committed , müssen Sie select-Anweisungen nicht in Transaktionen einschließen. Select-Anweisungen werden vor Dirty Reads geschützt, unabhängig davon, ob Sie sie in eine Transaktion einschließen oder nicht.
connection 1: connection 2:
begin transaction
update user set name = 'Bill' where id = 1
select name from users where id = 1
rollback transaction
Die Select-Anweisung liest die rückgängig gemachte Aktualisierung nicht:Es spielt keine Rolle, dass sie nicht in eine Transaktion eingeschlossen sind.
Wenn Sie wiederholbare Lesevorgänge benötigen , dann hilft das Umschließen von Auswahlen in einer Standardtransaktion nicht:
connection 1: connection 2:
begin transaction
select name from users where id = 1
update user set name = 'Bill' where id = 1
select name from users where id = 1
commit transaction
Der begin und commit Anweisungen helfen hier nicht:die zweite select kann Lesen Sie den alten Namen, oder es kann lesen Sie den neuen Namen.
Wenn Sie jedoch auf einer höheren Isolationsstufe ausgeführt werden, wie z. B. serializable oder repeatable read , wird die Gruppe vor nicht wiederholbaren Lesevorgängen geschützt:
connection 1: connection 2:
set transaction isolation level
repeatable read
begin transaction
select name from users where id = 1
update user set name = 'Bill' where id = 1
select name from users where id = 1 |
commit transaction |
|--> executed here
In diesem Szenario ist das update blockiert, bis die erste Transaktion abgeschlossen ist.
Höhere Isolationsstufen werden selten verwendet, da sie die Anzahl der Personen verringern, die gleichzeitig in der Datenbank arbeiten können. Auf der höchsten Ebene serializable , stoppt eine Berichtsabfrage alle Aktualisierungsaktivitäten.
