Транзакция в SQLite: как няколко промени стават една операция

Полезно е да знаеш

Една задача в приложението може да изисква няколко промени в базата данни. Ако те са свързани, частичното им изпълнение може да остави нежелано състояние. Транзакцията позволява тези промени да бъдат разглеждани като обща операция. При потвърждение с COMMIT те се запазват, а при отказ с ROLLBACK се отменят според правилата на базата. В SQLite командата BEGIN може изрично да започне транзакция, която обхваща последващата работа до нейното приключване. [1]

Атомарността означава, че промените в една транзакция се проявяват като извършени изцяло или неизвършени. SQLite описва механизмите, чрез които осигурява такова поведение при записване на данните. [2] Това е гаранция за организацията на операцията, а не оценка дали самите стойности са правилни. Ако приложението успешно потвърди грешна цена, атомарността няма да избере друга цена вместо него. Коректността на правилата и недопускането на частичен запис са различни части от надеждната работа.

Нека имаме измислена система за записване на участници в работилница. При потвърждаване трябва да бъде създадено записване и да се актуализира броят на свободните места. Преди програмирането е полезно да се опише състоянието, което е допустимо след операцията. И двата записа трябва да съответстват на едно и също решение. Този пример показва защо границата на транзакцията трябва да следва смисъла на задачата, вместо произволно да обхваща само удобната за писане заявка.

SQLite допуска множество едновременни транзакции за четене от отделни връзки, но само една едновременна транзакция за запис. Има различни начини за започване, включително DEFERRED и IMMEDIATE, с различен момент на придобиване на необходимата възможност за запис. [1] Това е важно за приложенията, които обработват конкуриращи се действия. Не е достатъчно да се добави думата transaction и да се приеме, че всяка ситуация на едновременен достъп вече има подходящо поведение.

Практическият тест може да предизвика неуспех след първата от две свързани промени. След приключване проверяваме базата, а не само показаното съобщение. Останал ли е първият запис? Променен ли е броят на местата? После изпитваме успешния сценарий и повторен опит. Така се проверява конкретният договор на приложението: кои промени принадлежат заедно и какво състояние трябва да остане при всяка избрана развръзка на операцията.

Транзакцията в базата не описва автоматично съдбата на всички външни действия, например вече изпратено съобщение. Затова при проектиране е полезно отделно да се изброят записите и останалите ефекти. За всеки от тях се определя кога е допустимо да настъпи и как се реагира при неуспех. Атомарността е силен механизъм за свързаните промени в базата, когато границите на операцията са ясни и тестовете проверяват действителното крайно състояние.