Какой смысл включить избранные операторы в транзакцию?
Какой смысл включить избранные операторы в транзакцию? Я думаю, что избранные операторы, просто "ПОЛУЧАЮТ" данные из базы данных, у них нет шанса откатывать что-то, потому что Вы просто не можете изменить данные. Так, это для высказывания мы никогда не должны поместить избранные операторы в транзакцию?Я прав?
Спасибо.
7 ответов
Вы правы: на стандартном уровне изоляции , чтение зафиксировано , вам не нужно заключать операторы выбора в транзакции. Операторы выбора будут защищены от грязного чтения вне зависимости от того, включаете ли вы их в транзакцию или нет.
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 может прочитать старое имя или может прочитать новое имя.
Однако, если вы работаете на более высоком уровне изоляции, например сериализуемое или повторяющееся чтение , группа будет защищена от неповторяющихся чтений:
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
В этом сценарии, обновление будет заблокировано до завершения первой транзакции.
Более высокие уровни изоляции используются редко, поскольку они сокращают количество людей, которые могут одновременно работать с базой данных. На самом высоком уровне, сериализуемый , запрос отчета останавливает любую операцию обновления.
Нет.
Транзакция дает вам единообразное представление о базе данных.
Если вы хотите, чтобы ваши выборки возвращали те же результаты при их повторении, транзакция может предоставить это.
Если вы уверены, что все, что происходит - это SELECT, то это не обязательно должно быть в транзакции. Вы на 100% уверены, что сейчас и навсегда это будет только SELECT?
.Один оператор SELECT является атомарным для начала - заключать его в транзакцию излишне. Если есть несколько операторов SELECT, вы гарантированно уверены, что никто не изменил ничего, влияющего на любой из них, пока все они не завершатся.
Возможно, вы не изменяете данные, но какое-то другое подключение к базе данных может это сделать.
Возможно, вы выполняете другие обновления / вставки во время этой транзакции. Если ваш код, обращающийся к базе данных, написан с возможностью повторного использования, вы не можете не знать, является ли выборка единственной вещью, происходящей в транзакции.
Ваши операторы select могут быть согласованными на протяжении всей транзакции, а также согласовываться с изменениями данных, происходящими в других транзакциях. Вы захотите установить какой-то уровень изоляции в своей системе, чтобы предотвратить «грязное» чтение (чтение незафиксированных изменений в другой транзакции) или фантомное чтение (чтение зафиксированных изменений в другой транзакции).
Излишне говорить, что транзакции будут лучше обслуживать вас.
Еще одна причина использовать транзакции с select:
Возможно, в какой-то момент вы захотите вызвать свой метод select из других методов, которые участвуют в транзакции, и вы захотите, чтобы select участвовал в текущей транзакции. Если у вас последовательный дизайн, где все действия с базой данных выполняются в транзакции, то вызывающие любой метод знают, что он будет участвовать в их транзакции.
При небольших предварительных затратах на разработку это может помочь избежать довольно больших изменений в дальнейшем, пытаясь впихнуть транзакции, если/когда требования изменятся или добавятся новые требования.