Je hebt gelijk:op het standaard isolatieniveau
, read committed , hoeft u select-overzichten niet in transacties in te pakken. Select-afschriften worden beschermd tegen vuile lezingen, of u ze nu in een transactie verpakt of niet.
connection 1: connection 2:
begin transaction
update user set name = 'Bill' where id = 1
select name from users where id = 1
rollback transaction
De select-instructie leest de teruggedraaide update niet:het maakt niet uit dat ze niet in een transactie zijn verpakt.
Als u herhaalbare leesbewerkingen nodig heeft , dan helpt het niet om selecties in een standaardtransactie in te pakken:
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
De begin en commit uitspraken helpen hier niet:de tweede select mag lees de oude naam, of het mag lees de nieuwe naam.
Als u echter op een hoger isolatieniveau werkt, zoals serializable of repeatable read , wordt de groep beschermd tegen niet-herhaalbare leesbewerkingen:
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 dit scenario is de update wordt geblokkeerd totdat de eerste transactie is voltooid.
Hogere isolatieniveaus worden zelden gebruikt omdat ze het aantal mensen dat tegelijkertijd in de database kan werken, verlagen. Op het hoogste niveau, serializable , stopt een rapportagequery elke update-activiteit.