|
Е, примерът с банковата транзакция е просто... пример. Опростен. И не съм го измислил аз. Мога да дам пример и с транзакцията "смяна на спукана гума", например, изградена от операциите "развиване на болт" (по 4), "сваляне на старата гума", "слагане на новата", "завиване на болт" (по 4). И ситуацията, в която при развиването на третия болт, той се чупи заради корозия и остава вътре. Или механикът получава инфаркт. Или възниква какъвто и да е друг непредвиден проблем. Като нещо такова се случи, цялата логическа операция се проваля. Не може да имаш спукана гума, сменена наполовина. Това няма никакъв смисъл.
В отговор на:
Ако действаме по твоята логика, че отговорността е изцяло на сървъра и му се доверим, че ще открие всички проблеми какво се получава в този случай? Атомарна транзакция, която оставя боза след себе си.
Да. Естествено, че сървърът няма как да гарантира, че се изпълняват правилните заявки - той не знае кои са правилни и кои - не, освен ако не съм задал съответните ограничения (constraints), които да му го подсказват. А той знае кои заявки са предизвикали грешки и това автоматично означава, че нещо не е наред. Съответно сървърът трябва да гарантира, че транзакциите са истински "кисели" такива (ACID).
Никъде из нещата, които прочетох, нямаше "Транзакциите в СУБД могат да бъдат атомарни, ако клиентът бъде много внимателен, ама иначе всъщност не са.", а имаше "СУБД трябва да гарантира, че транзакциите са атомарни."
Има известна разлика. Всъщност това е и нещото, около което се върти спора ни - чия е отговорността.
Относно сериозния ти въпрос за случаите, в които би ми потрябвал ROLLBACK, мисля, че сам си дал един възможен отговор с дадения от теб пример за 0 засегнати реда.
"Договор, подписан с Русия, струва по-малко от хартията, върху която е написан!" - Бисмарк
|
Re: прехвърляне на топката [re: salle]
