Почему незафиксированная транзакция может изменять данные?

Question

[yourisus]

Собственно вопрос - почему транзакция, которая не завершена(commit), способна менять данные в кеше, а не создавать копию обьекта или хотя бы копию измененной части.
Вот у нас есть ситуация как на скрине:
1) Почему нельзя проверить действия на целостность и корректность, а потом после утверждения(commit) изменить данные? Создать локальную А, записать в нее, после утверждения, записать в ту, что в кеше, тем самым исчезнет, проблема "грязных данных".
2) Каким образом, после всех действий даже после перезаписи А, мы получили rollback?(как я понимаю, если А перезаписано, то бд как бы фактически проверила на целостность и тп.)
3) Расскажите, кто отдает конечное "зафиксировать\откатить"?
Ну или укажите на ошибки, может я чего-то не догнал...

Comments

[sim3x]

какая субд?

[yourisus]

sim3x: эм, я если честно не знаю, но сейчас лаббы идут на файл-серверной ms Access.
Просто я думал в книге идут принципиально общие понятия, для всех СУБД.

[sim3x]

yourisus: нет, не общие

Кроме стандартов, реализация в каждой субд различаются

Потому операции с деньгами, при правильной организации процесса, никогда не идут через апдейт.
Создается таблица странзакциями прихода/ухода денег, а потом делается сумма по ним

[yourisus]

sim3x: хорошо, а тут пример показан, он в mysql\postgree к примеру актуален, или же нет?

[sim3x]

yourisus:
покажи весь текст запросов и задачу вцелом

[yourisus]

sim3x: я перезалил полную страницу, тема "Управление параллелизмом" и далее рассматриваются ситуации, которые могу возникнуть при распараллеливании.

Answer 1

[Melkij]

Читайте далее. Это, судя по всему, прелюдия к описанию уровней изоляции транзакций.
READ UNCOMMITTED - позволяет СУБД показывать данные, которые ещё не были зафиксированы. Это не значит, что именно так на этом уровне изоляции должна так себя вести СУБД, но поведение допускается стандартом для этого уровня изоляции. Например, в упомянутом postgresql на шаге t4 900 вы не сможете получить никогда, даже на read uncommitted.

Comments

[yourisus]

спасибо, вроде понял.

Answer 2

[bnytiki]

Далеко не всегда важны "чистые" данные, бывает, что важнее скорость.

Вот два примера:

Например, какая вам принципиальная разница - будет на 1 лайк больше или нет?
С другой стороны, при банковских операциях мелочи важны.

Чем "чище" тем выше нагрузка на СУБД.
Поэтому иногда ОСОЗНАНО снижают "чистоту".

Answer 3

[sim3x]

stackoverflow.com/questions/6477574/do-database-tr...