Гласът на разума ....

Нека си представим следната ситуация:
1. Стартираме транзакция
2. Операция О1 -> ok
3. Операция О2 -> error
4. Операция О3 -> ok
5. В зависимост от резултатите клиента тук решава Commit или Rollback

За Rollback е лесно - отменя се всичко
Но за Commit трябва да се потвърдят О1 и О3.
Ако е вярно това със неявния Rollback и стартиране на нова транзакция, то Commit в т.5 би потвърдил само О3.
Ако в MySQL се потвърждава само О3 - има нещо гнило.
Вероятно става въпрос по-скоро за Rollback до неявен Savepoint в началото на всяка операция


Работата е там, че Dakota иска сървърът да отхвърли всичките O1, O2 и O3 ако има каквато и да е грешка в който и да е от трите.

Примерът който му дадох с неявния ROLLBACK до началото на транзакцията беше за хипопетичен сървър, който го прави за всякаква грешка в опит да демонстрирам, че и в този случай е задължение на клиента да прекрати изпращането на последващи оператори - О3 в твоя пример.

Хейки Туури от самото начало е писал InnoDB като конкурент на Оракъл и затова го е направил да реагира по същия начин. Когато O2 даде грешка се връща само O2 все едно има неявен savepoint преди всеки оператор.

1. Стартираме транзакция
Неявен savepoint S1
2. Операция О1 -> ok
Неявен savepoint S2
3. Операция О2 -> error
Неявен savepoint S3
4. Операция О3 -> ok
ROLLBACK до S2
5. При евентуален COMMIT се потвърждават О1 и О3.


За Dakota:
Клиента решава Commit или Rollback. Не сървъра !!!
Сървъра има задължението да информира за успеха/неуспеха на всяка операция и да потвърди всички успешни при желание на клиента (Commit) или да отмени всички при желание на клиента (Rollback).

Отлично казано! Записвам си в бележките

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите