Рамката няма начин да разбере дали сте започнали транзакция. Можете дори да използвате $db->query('START TRANSACTION') за които рамката не би знаела, защото не анализира SQL изразите, които изпълнявате.
Въпросът е, че отговорността на приложението е да проследи дали сте започнали транзакция или не. Това не е нещо, което рамката може да направи.
Знам, че някои фреймворки се опитват да го направят и правят глупави неща като броене колко пъти сте започнали транзакция, като я разрешават само когато сте извършили ангажимент или връщане назад същия брой пъти. Но това е напълно фалшиво, защото никоя от функциите ви не може да знае дали commit или rollback наистина ще го направят, или дали са в друг слой на влагане.
(Можете ли да кажете, че съм водил тази дискусия няколко пъти? :-)
Актуализация 1: Propel е PHP библиотека за достъп до база данни, която поддържа концепцията за "вътрешната транзакция", която не се ангажира, когато й кажете. Започването на транзакция само увеличава брояча, а извършването/връщането намалява брояча. По-долу е даден откъс от нишка от пощенски списък, където описвам няколко сценария, при които не успява.
Актуализация 2: Doctrine DBAL също има тази функция. Наричат го влагане на транзакции.
Харесвате или не, транзакциите са „глобални“ и не се подчиняват на обектно-ориентирано капсулиране.
Проблемен сценарий №1
Извиквам commit() , ангажименти ли са промените ми? Ако изпълнявам вътре във "вътрешна транзакция", те не са. Кодът, който управлява външната транзакция, може да избере да се върне назад и промените ми ще бъдат отхвърлени без мое знание или контрол.
Например:
- Модел А:започване на транзакция
- Модел A:изпълнете някои промени
- Модел Б:започване на транзакция (безшумно без операция)
- Модел Б:изпълнете някои промени
- Модел Б:извършване (безшумно без операция)
- Модел А:връщане назад (отхвърля както промените в модел А, така и промените в модел Б)
- Модел B:WTF!? Какво се случи с промените ми?
Проблемен сценарий №2
Вътрешна транзакция се връща назад, тя може да отхвърли законните промени, направени от външна транзакция. Когато контролът се върне към външния код, той вярва, че неговата транзакция все още е активна и е налична за ангажимент. С вашата корекция те биха могли да извикат commit() , и тъй като transDepth вече е 0, той ще зададе тихо $transDepth до -1 и върнете true, след като не сте извършили нищо.
Проблемен сценарий №3
Ако извикам commit() или rollback() когато няма активна транзакция, той задава $transDepth до -1. Следващият beginTransaction() увеличава нивото до 0, което означава, че транзакцията не може нито да бъде връщана назад, нито да бъде ангажирана. Последващи извиквания на commit() просто ще намали транзакцията до -1 или повече и никога няма да можете да извършите ангажимент, докато не направите още един излишен beginTransaction() за да увеличите нивото отново.
По принцип опитът да се управляват транзакции в логиката на приложението, без да се позволява на базата данни да води счетоводството, е обречена идея. Ако имате изискване за два модела да използват изричен контрол на транзакциите в една заявка за приложение, тогава трябва да отворите две DB връзки, по една за всеки модел. Тогава всеки модел може да има своя собствена активна транзакция, която може да бъде ангажирана или връщана назад независимо една от друга.
