Анотация: В тази глава се анализират подробно същността на "сделка" понятия, да научат как да работят InterBase предлага сделка запознае с мулти-версия архитектура, ще разгледаме нивата на изолация сделка. В един практически пример, да създадете приложение, което работи едновременно с две сделки.
По време на курса, ние не просто трябва да се справят с този термин. Темата на "сделки" в InterBase не е лесно, но е много необходимо да се разбере. Тази лекция е посветена на теорията на сделка. и практически приложението им в заявленията.
. В "Въведение в базата данни на клиент-сървър на InterBase" споменахме, че сделката - тази заявка пакет, който постоянно произвежда промени в базата данни и или да се приеме, ако всички промени се потвърждават записи или отхвърлени, ако най-малко една молба не успя. Заявките могат да съдържат оператори SELECT / INSERT / UPDATE / DELETE. и може да бъде един като въпрос в контекста на една сделка. и много заявки. Въпреки това, терминът "сделката" е много по-дълбоко от това кратко определение.
Сделки се стартират от страната на сървъра, и те ще започнат само по заповед на заявката на клиента. Усъвършенстването на работа те са и по заповед на приложението на клиента, както и при успешно приключване на сделката, се потвърждава и ако не успее - се отхвърля. В тригери или процедури, за да предизвика началото на сделката не е възможно.
Транзакциите. в действителност, това е механизъм, който ви позволява да извършвате различни действия на базата данни като отделна логическа единица, която взема на базата данни от една последователна състояние в друго. Или не върне, ако сделката е била отхвърлена.
Ние се убедите в това са класически пример на прехвърлянето на пари в банката от една сметка в друга.
Да предположим, че нашите писти бази данни без сделка. и ние трябва да се произведе, каза превода. След това можем да се процедира по два различни начина:
- Първоначално, ние премахваме пари от една сметка, а след това го добавите към друга сметка.
- Първоначално добавите пари в друга сметка, а след това да ги премахнете от първата сметка.
Сега предполагам, че в средата на тази операция, е имало повреда: затвори сървъра на базата данни. например. В първия случай, парите ще бъдат загубени - те отидоха от един профил, но не достигна на другия. Във втория случай, на пари "размножават" - ще се появи на втория ред, но в същото време и ще остане на земята. И в действителност, а в друг случай, нарушаване на целостта на базата данни се случва - данните ще бъдат ненадеждни.
Въпреки това, всички бази данни SQL -server работят с транзакции. Те също така казват, че всички промени на базата данни се осъществява в контекста на една или повече сделки. InterBase не е изключение. Освен това, InterBase осигурява много по-гъвкав инструмент за управление на сделка. отколкото много други SQL -server. Ако има неизправност, че при прехвърляне на пари, сделката не е потвърдена, а базата данни остава в същото състояние - целостта и надеждността на базата данни не е счупена.
Валентност (валентност)
Атомност означава, че една сделка е мерна единица за работа с базата данни. много модификации на базата данни може да се случи в рамките на една сделка. обаче, сделката се действа на принципа на "всичко или нищо". Когато сделката се потвърждава (комит), потвърди, че всички промени, направени в неговия контекст. Когато тя е отхвърлена (дърпа назад, намаление на цените), се отхвърля и всички промени. В случай на неуспех, системата се възстановява, премахва ефекта от сделката. не е имал време да завърши.
Последователността (Последователност)
По силата на споразумението, трябва да се разбира, че целостта на базата данни не може да бъде разбита, въпреки че е имало сделка е потвърдена. или отхвърли. В резултат на това на базата от данни за транзакциите отива от една съгласувана и последователна състояние в друго. Ако сделката бъде отхвърлена, се променя на базата данни се случват.
От страна на сървъра за съвместимост отговарят на проверката ограничения. референциален интегритет ограничения и тригери. Софтуер, обаче, трябва да бъдат внимателно проектирани механизми на бизнес логика.
Изолиране (Изолиране)
Базата данни може да се изпълнява едновременно много транзакции. Това се случва, че две или повече сделки се опитват да променят един и същи запис. За да се гарантира целостта на данните, сделките се извършват в изолация един от друг. Можем да кажем, че всяка транзакция се изпълнява със собствен копие (версия) на данни. Има няколко нива на изолация сделка. това, което следва, ще говорим по-подробно.
Устойчивост (издръжливост)
Ако сделката е успешен, направените промени в своя контекст, трябва да бъдат стабилни и поддържани, независимо от грешките в други сделки. грешка или хардуер се срине сървъра. С други думи, резултатите от успешно завърши сделката е физически, съхранявани в базата данни.
Явни и неявни старт сделка
Всички действия на базата данни, ангажирани с прилагането на клиента, се случват вътре (в контекст) сделката. В предишните лекции примери, ние се свърже с клиентски приложения, бази данни, всички без използването на сделка. Все пак, това не означава, че те не са били. Само една сделка се стартира по подразбиране, автоматично. И с параметрите, установени Делфи "по подразбиране". В тежки приложения за бази данни, е недопустимо, тъй като това може да доведе до множество конфликти.
Транзакция може да започне и ясно. От стандартните механизми за достъп, които използваме най-вече, InterBase Express (IBX). Заявлението трябва да присъстват най-малко. IBTransaction един компонент. С този компонент, трябва изрично да зададете параметрите на сделката. контролира старт, потвърждение или обратно сделката. Това се прави с помощта на следните методи на боб:
- StartTransaction - Стартиране на сделка.
- Поемане на ангажимент - Потвърждение на сделката, след което да го затворите.
- CommitRetaining - Потвърждение на сделката, без да го затваря.
- Намаление на цените - намаление на цените сделка с последващо затваряне.
- RollbackRetaining - Връщане на сделка, без да го затваря.
Въпреки това, компонентите достъп до данните по подразбиране стартиране на сделка. така StartTransaction обикновено пропуснете. Но потвърждение или проверка намаление на цените, обикновено в опитате ... с изключение на блок в приложението на клиента:
В този пример, ако сделката е успешна, данните се съхраняват нормално. В случай на всяко съобщение за грешка се показва и сделката се завъртя обратно.
Тъй като сделката се изпълнява
В базата данни има специална зона, наречена Съвет (транзакция Инвентаризация страница - Инвентаризация Транзакции). В началото на сделка. тя се определя идентификатор (три пъти дневно Идентификационен номер на транзакцията.) - инвентарен номер, който се съхранява в бакшиш. В този случай, в последния сделката ще бъде най-голямата идентификатор. Върхът. в допълнение към номерата за започване на сделка. запаметена и нейното състояние, което може да бъде активен (в работата), Ангажиран (потвърдено), отвали (Отменен, намаление на цените), и в състояние на неопределеност (Несигурно).
Тя е наречена активна сделката. която в момента е в процес на изпълнение.
Потвърдено сделката се нарича. Той е завършил успешно своята работа, като правило, по команда Ангажиране.
Отменен сделка повикване. който не успя. В същото време се връщам действия, извършени от нея, като правило, екип RollBack.
Несигурно транзакция (Limbo) се нарича транзакция. който работи едновременно с две или повече бази данни. След приключване на тази сделка. InterBase прави двуфазов протокол за записване на данни. гарантира, че промени ще бъдат направени или във всички бази данни. или която и да е. В този случай потвърждаване на бази данни, ще бъде даден в даден момент. Ако в този момент има провал система, тя може да се окаже, че са направени промени в публичните бази данни, както и в това, което не е така. В този случай, сделката влиза неопределен състояние, когато сървърът не знам дали да потвърди сделката. или се връщам.
Всяка транзакция. започване на работа, създава своя собствена версия на записите в таблицата, която работи. запис на версия - е копие на запис, който се създава, когато сделката се опитва да го промените. По този начин, всеки запис в таблицата, може потенциално да има няколко версии, всяка със собствен сделка работен вариант на този запис. Ако сделката се променя данните, тя се променя своя собствена версия на записа, а не в оригинал. Освен това, сделката може или да потвърди или отмени.
Ако сделката бъде потвърдена, InterBase опитва да маркирате предишното оригиналния запис. както и дистанционно версия на сключената сделка - като оригинала. Когато InterBase записва промените, новия запис се поставя и идентификационен номер на транзакцията. който е направил тези промени (всеки ред от таблицата съдържа идентификатора на сделката, която го е създал).
Ако сделката е неуспешна, на оригиналния запис и оригиналните останки.
Ако сделката се чете само на запис. без да се опитва да го промени, той не създава своя собствена версия за нея.
Въпреки това, може да има конфликти и сделки. Да предположим, че започна Т1 сделка. Тя е създала версия на записа, и да се промени своите данни. По това време, той започна състезава T2 сделка, и е създал версия на същия запис. Тъй като T1 още не е приключило, T2 не можеше да види данните в началото на промените, направени от T1 и следователно, създава своя версия на стария оригинала. T1 сега се финализира ангажират. Какво трябва да направи InterBase. Ако това ще отбележи T1 версия на записа като оригинала, но старият рекорд. как дистанционно, версията на Т2 ще бъде невярна информация! InterBase действия в този случай ще зависи от параметрите на сделката. по-долу, ние ще говорим по-подробно.
Ако сделка премахва някои низ, низа не е физически премахнат от базата данни. но само маркирани като дистанционно управление, поддържане и премахване на стая сделка нея. Ако сделката се провали, премахване на реалната линия не се случва, тъй като не е имало потвърждение.
По този начин, се казва, че мулти-версия InterBase архитектура (MGA - Multi Generation Architecture). Тази архитектура позволява да се организира работата с базата данни, така че потребителите да не блокират читатели, които пишат. В допълнение, в случай на отказ на системата, на InterBase бързо възстановяване, благодарение точно до MGA. Между другото, това е първият от InterBase SQL -Server, който поддържа мулти-версия архитектура.
Наред с предимствата на този подход, в базата данни с данните, времето се натрупва "боклуци". Всяка транзакция. опитват да променят данните, създава своя собствена версия на линиите, и ако не се грижи за своевременното отстраняване на стари, вече безполезни версии на базата данни скоро ще бъде просто запушени отломки.
Но как да се отстранят боклука? Мога ли да премахна версията на сделката. което приключи, успешно или неуспешно? Не, ако тази версия в момента се използва от други сделки. По-късно ще говорим за нивата на изолация сделка. а само да кажа, че някои операции могат да се видят промените, направени от други, все още не е потвърдено от активни операции.
Да предположим, че започна Т1 сделка. Тази транзакция създаде версия на записа и да го модифицирате. По-късно започнах сделка Т2, която е създадена, така че можете да видите всички промени, дори и да не потвърди. Тя апелира към един и същи запис, и тъй като тя иска да види последните промени, тя осигурява версия на Т1 сделка. Тогава T1 приключи своята работа, но T2 все още работи с версия на записа, затова тази версия не може да бъде изтрита.
В момента InterBase механизъм за премахване на старите версии, а именно новите сделки. Нова сделка. с искане за влизане. Четох всички версии на този запис. В този случай, се прави проверка за това дали сделката е била. Тази версия е отменен (RollBack) или потвърдени (комит). Ако сделката е била отменена, така че тази версия - отломки, които трябва да бъдат отстранени. Ако има няколко версии, направени от извършените сделки. датата счита за версията с най-голям номер на транзакцията. Други версии се считат остарели и също подлежат на премахване.
По този начин, млад транзакция почисти базата данни на отломки, оставена от по-стари сделки. Но те не почистват версия всички стари в един ред, но само версията на записа (или записи), за които се разгледа себе си.
Тъй като сървърът може да работи едновременно много транзакции. Има терминология определения на тези сделки.
- Active сделка - сделка, която е започнал, но все още не е завършена.
- Интересува сделка - сделка, се конкурира с текущата сделката.
- Най-старият активен сделката - това е такава активна транзакция. който е започнал по-рано от другите. Както и да е, това е активна транзакция на най-ниското ID.
- Най-старият съответната сделка - тя е такава интересуват сделка. който е започнал по-рано от другите. Както и да е, той се занимава с най-ниската идентификатор сделка.
В този контекст, събиране на боклука е най-старият действащ сделката. От записа версии, направени от по-млади сделка. тя не може да види, а след това го премахва отломките, оставени от други по-големи сделки. Когато сделката приключи своята работа, статут на "най-старият действащ" се измества на следващата сделката. По този начин, сделката се предава един на друг дълг на събиране на боклука.
Свързани статии