Четете онлайн World of InterBase
Това ниво на изолация често се използва за получаване на „най-свежото“ състояние на база данни.
Както показва таблица 1.4, има два вида на това ниво на изолация: read_committed rec_version и read_committed no_rec_version. По подразбиране се използва вариантът с параметъра rec_version. Това означава, че когато се чете запис, той просто чете последната потвърдена версия на записа.
Опцията no_rec_version е по-трудна за обяснение. Най-общо казано, смисълът на използването на нивото read_committed с опцията no_rec_version е "че транзакцията не само ще се опита да прочете най-новата ангажирана версия на записа, но също така ще изисква да няма по-нова не ангажирана версия.
Когато се чете запис в такава транзакция, се прави проверка дали записът има некоммитирана версия. Ако съществува, тогава се случва следното (в зависимост от избрания режим на блокиране):
* Ако се изчака, тогава нашата транзакция изчаква, докато транзакцията, която е създала неангажирания запис, завърши. И ако бъде потвърдено или отменено, тогава се чете последната потвърдена версия.
* Ако заключването е nowait, веднага се появява грешка „Deadlock“.
Очевидно нивото на изолация read_committed no_rec_version може да доведе до много конфликти и трябва да се използва много внимателно.
Нивото на изолацияSNAPSHOTсе задава от параметъра за едновременност. Можем да кажем, че SNAPSHOT е най-„родният“ режим на InterBase, в който предимствата на версията се проявяват най-пълно. Когато се използва, транзакцията прави „моментна снимка“ на маската на транзакция в базата данни в момента, в който е стартирана, и следователно, докато трае, вижда същите данни, които са съществували, когато е стартирана.Всички промени, направени от паралелно работещи транзакции, не са видими за него. Тя вижда само своите промени. Ако се опитате да промените данни в тази транзакция, които са били променени от други транзакции след стартирането й (което означава както вече ангажирани, така и непотвърдени данни), възниква конфликт.
Докато транзакция с паралелна изолация е в ход, всички версии на запис се съхраняват в момента, в който е стартирана, тъй като едновременните транзакции виждат, че SNAPSHOT е активен и нямат право да събират версии на записи, тъй като нашият SNAPSHOT може (хипотетично) да се нуждае от тях.
Обикновено SNAPSHOT се използва или за отнемащи време заявки (отчети), или за заключване на записи, за да се предотврати едновременното им редактиране/изтриване от други транзакции.
Очевидно използването на това ниво на изолация ви позволява да организирате последователни (сериализирани) актуализации на таблици. Обикновено това ниво на изолация се използва само за кратки транзакции за опресняване. Транзакцията започва, прави много кратка промяна и излиза веднага.Други транзакции, в зависимост от режима на блокиране на изчакване или сега, или изчакват реда си, или предизвикват изключение.
Указания за използване на параметри на транзакция
Как да използвате транзакции - този въпрос често се сблъсква с начинаещи разработчици. Разбира се, за всяка конкретна задача е необходимо да се реши въпросът индивидуално. Обикновено всички заявки към базата данни са разделени на групи – заявки за четене на „най-свежото“ състояние на базата данни, заявки за текущи промени, заявки за четене на справочни таблици, заявки за четене на данни за създаване на отчет и т.н. Всяка група заявки обикновено има своя собствена транзакция (или групатранзакции) с набор от параметри, необходими за изпълнение на задачата.
Как да настроите транзакции за такова приложение?
За заявка SELECT. ., който чете данни в мрежата, трябва да използвате транзакция само за четене с ниво на изолация READ COMMITED, за да получите „най-пресните“ данни от таблицата веднага щом бъде актуализирана/добавена (не забравяйте, че нашето приложение е многопотребителско и няколко приложения могат да работят едновременно). Примерен набор от параметри е както следва:
Това гарантира четене на всички записи, потвърдени от други транзакции, и без конфликти с едновременни транзакции за запис и четене.
Такава транзакция може да се държи отворена дълго време - сървърът не е зареден с версии на запис.
За заявка за промяна/добавяне на данни можете да използвате транзакция с ниво на изолация на паралелността. Заявката за актуализиране в този случай трябва да бъде много кратка: потребителят попълва задължителните полета, транзакцията се стартира, прави се опит за изпълнение на заявката и след това, ако няма n> конфликт на запис с друга транзакция, потвърждение на нашата транзакция или връщане назад, ако е имало конфликт (на ниво клиентско приложение конфликтите се появяват като изключения, които са удобни за улавяне с помощта на оператори try.. .except или try.. .catch copy)
Параметрите на такава сделка ще бъдат както следва:
Такъв набор от параметри ще ни позволи незабавно (сега да изчакаме) да открием, че записът се редактира/променя от друг потребител (ще възникне грешка), както и да попречи на други потребители да се опитват да започнат да променят записите, трансформирани от нашата транзакция (претендентът ще има грешка „конфликт на актуализиране“). Трябва да се отбележи, че преди да редактирате, трябва да прочетете отновозапис, тъй като може да е бил модифициран и кешът на мрежата може все още да има стара версия
За заявки, които се използват за създаване на отчети, определено трябва да използвате транзакция с режим на достъп само за четене и ниво на изолация на едновременност:
Такава транзакция ще върне точно данните, които са съществували в момента на нейното стартиране - това е много важна функция за отчети, които се изграждат в няколко преминавания през базата данни.
За заявки за четене на референтни данни можете да използвате транзакция, подобна на заявка SELECT, за да извлечете данни в мрежа.
Отвъд транзакциите
Разгледахме общите въпроси, свързани с транзакциите, както и спецификата на практическото им приложение в базата данни. В самото начало на главата беше казано, че всички действия в InterBase се извършват в контекста на транзакции.
Има обаче обекти, за които се твърди, че са извън контекста на транзакциите.Това са генератори и външни таблици.
Генераторът, както е описано в главата "Таблици. Първични ключове и генератори", е брояч, който съхранява някаква целочислена стойност. Въпреки това, чрез изпълнението си, генераторът е напълно уникален обект. За разлика от други данни в базата данни, стойностите на генератора се съхраняват на най-ниското физическо ниво - на специални страници на генератори. Това позволява на всички транзакции да виждат едновременно стойностите на генераторите във всеки един момент. Това е много ценна функция, която ви позволява да организирате вмъквания без противоречия в паралелни транзакции.