Ответ 1
Вы правы: на уровне уровень изоляции, read committed вам не нужно обертывать операторы select в транзакциях. Операторы Select будут защищены от грязных чтений, переносите их в транзакцию или нет.
connection 1: connection 2:
begin transaction
update user set name = 'Bill' where id = 1
select name from users where id = 1
rollback transaction
Оператор select не будет считывать обновленное обновление: не имеет значения, что они не заключены в транзакцию.
Если вам нужно repeatable reads, то обертывание в транзакции по умолчанию не помогает:
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 запрос отчета останавливает любую активность обновления.