Прав сте:на стандартното ниво на изолация
, read committed , не е необходимо да обвивате избрани отчети в транзакции. Изявленията за избор ще бъдат защитени от мръсни четения, независимо дали ги обвивате в транзакция или не.
connection 1: connection 2:
begin transaction
update user set name = 'Bill' where id = 1
select name from users where id = 1
rollback transaction
Операторът select няма да прочете върнатата актуализация:няма значение, че те не са обвити в транзакция.
Ако имате нужда от повтарящи се четения , тогава обвиването на селектирания в транзакция по подразбиране не помага:
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
begin и commit изразите няма да помогнат тук:вторият select може прочети старото име, инакможе прочетете новото име.
Ако обаче работите на по-високо ниво на изолация, като serializable или repeatable read , групата ще бъде защитена от неповтарящи се четения:
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
В този сценарий update ще блокира до завършване на първата транзакция.
Рядко се използват по-високи нива на изолация, тъй като те намаляват броя на хората, които могат да работят в базата данни едновременно. На най-високо ниво, serializable , заявка за докладване спира всяка дейност по актуализиране.
