Реферат Обробка транзакцій

Страница 1 из 2 | Следующая страница

Зміст

 

Запровадження……………………………………………………..………………….... 3

1. Основи обробки транзакцій…………………………..………………….... 4

2. Принципи і моделі обробки транзакцій…………..……………….......... 5

2.1. Пласкі транзакції………………………..……………………….... 6

2.2. Контрольні точки………………………..…………………………. 8

2.3. Многозвенные транзакції…………………………………………. 10

2.4. Вкладені транзакцію………………………………………......... 11

3. Encina і DCE…………………………………………………………………. 14

4. X/Open DTP…………………………………………………………………... 17

5. Класифікація систем обробки транзакцій……………………………. 19

6. Мови транзакцій………………………………………………………......... 20

7. Мониторы обробки транзакцій третього покоління…………..……….. 21

Заключение……………………………………………………………………….24

Література

 

Запровадження

У цьому курсової роботі обговорюються тенденції і обробки транзакцій на застосування до системам інформаційного управління у цілому. Розглядаються, зокрема, такі питання:

§ принципи обробки транзакцій на інформаційних системах;

§ останні досягнення у світі комерційних систем обробки транзакцій;

§ мови обробки транзакцій;

§ стандарти;

§ риси систем обробки транзакцій для наступного покоління.

 

1. Основи обробки транзакцій

Можна розглядати обробку транзакцій на узагальненому вигляді, включаючи безліч парадигм - від пакетної та простий терминально-интерактивной обробки (насправді концептуальними джерелами комп'ютерного опрацювання транзакцій вважатимуться шумерські глиняні таблички з записами торгових операцій, зробленими за багато тисячоліття до зародження ідеї обчислювальної машини). Конкретніше, дисципліна транзакцій включає у собі різні функції на підтримку комп'ютерних додатків, заснованих на виключно комунікаціях. У узагальненому сенсі системи обробки транзакцій можуть охоплювати усе, що можуть бути у комп'ютерній системі: бази даних, мережі, операційні системи й т.п.     

У сфері обробки транзакцій має місце наступна класифікація (рис. 1).

Малюнок 1. Покоління систем обробки транзакцій.

 -   Перше покоління. Єдині монолітні системи, які з користувачем у вигляді найпростіших терміналів.

 - Друге покоління. Підтримка продуктів багатьох постачальників, інтелектуальні клієнтські системи, підтримка безлічі систем баз даних, зазвичай, з допомогою протоколів двухфазовой фіксації (в другому поколінні відбиває нинішній стан справ у цій галузі).

-   Третє покоління. Зарождающееся покоління систем, більш адекватно, чому це можливо сьогодні, що відбиває потреби бізнесу.

Хоча поняття "обробка транзакцій" застосовно практично до будь-якої комп'ютерної середовищі, особливо у бізнесі, проте традиційно використання моніторів обробки транзакцій обмежувалося окружениями великомасштабних центрів обробки даних, функціонуючих з урахуванням мэйнфреймов, в прикладних областях, як резервування авіаквитків чи міжнародні банківські операції. Останніми роками, почасти завдяки тому, що корпоративні інформаційні системи дедалі більше набувають риси распределенности і неоднорідності, монітори обробки транзакцій стали застосовуватися та у багатьох інших вертикальних додатках (охорону здоров'я, страхування, торгівля). За оцінками Gartner Group, до 1995 р. в 50% новостворених додатках з урахуванням реляционных СУБД придадуться кошти обробки транзакцій.

Звернімося тепер до фундаментальним принципам і основним моделям транзакцій, які визначають шляху застосування транзакцій на інформаційних системах.

2. Принципи і моделі обробки транзакцій

До всіх типам транзакцій пред'являється набір вимог, відомий під назвою ACID (atomocity, consistency, isolation, durability). Зміст вимог ось у чому.

Атомарность. Транзакция є певний набір дій. Система забезпечує виконання за принципом "усі поголовно чи нічого" - або виконуються всі дії, т. е. транзакція фіксується, або виконується жодна, т. е. транзакція переривається.

Узгодженість. Передбачається, у результаті транзакції система переходить вже з абстрактного коректного стану до іншого. Поняття транзакції дозволяє програмісту декларувати умови таких узгоджених станів даних, а системі - підтверджувати узгодженість, виробляючи достойні додатку перевірки.

- Изолированность. Оскільки транзакція змінює розділяються дані, вони можуть тимчасово перебувати у несогласованном стані. Дані, перебувають у несогласованном стані, нічого не винні бути видно іншим транзакциям, поки зміни буде завершено (т. е. доки всі модифікації ні формально зафіксовано). Система забезпечує кожної транзакції ілюзію те, що та виконується ізольовано, коли б інші транзакції або завершилися до початку спілкування, або почнуть виконуватися після завершення.

- Долговечность. Якщо транзакція зафіксована, що його результати би мало бути довговічними. Нові стану на всі об'єкти збережуться навіть тоді апаратних чи системних збоїв.

Існують численні моделі транзакцій, підтримують цих принципів. Вони варіюються від найпростіших, як-от "плоскі" транзакції, до витончених, як-от вкладені чи многозвенные. Розглянемо ці моделі докладніше, оскільки складні моделі у значною мірою визначають особливості обробки транзакцій на комерційних інформаційних системах майбутнього.

2.1. Пласкі транзакції

Моделі пласких транзакцій відповідає один управляючий шар, якій підпорядковано довільне число елементарних дій. У середовищі сучасних інформаційних системах - це, зазвичай, єдина підтримувана на прикладному рівні модель транзакцій, хоча внутрішні компоненти системи (наприклад, SQL) можуть включати витонченіші кошти обробки транзакцій; але вони не доступні лише на рівні прикладного програмування.

Пласкі транзакції - це основні будівельні блоки для реалізації принципу атомарности; інакше кажучи, виділення деякою послідовності дій як пласкою транзакції забезпечує принцип "усі поголовно чи нічого".

Багато прикладних оточеннях, особливо з централізованими опрацюванням і управлінням ресурсами (наприклад, базами даних, і файлами), механізм пласких транзакцій уже багато років надавав цілком задовільні можливості до створення, так виконання додатків; прості перетворення станів системи цілком вкладалися у рамки атомарних одиниць роботи.

Принаймні того як дані і обчислення стають дедалі більше розподіленими, атомарность пласких транзакцій стає значним незручністю. Розглянемо приклад на рис. 2. Відповідно до правил обробки пласких транзакцій, або повинні успішно завершитися все компоненти глобальної транзакції, або має завершитися жодна їх. Наприклад, якщо невдачею завершилося тільки зміну однієї віддаленій бази даних під керівництвом деякого менеджера ресурсів, те й й інші компоненти мають повернути до стану, попереднє початку транзакції. Зважаючи на кількість інформації, оброблюваної у великій і навіть середньої організації з безліччю серверів LAN на ПК і, можливо, з мобільними базами даних, можна припустити, що ймовірність відмови хоча самого вузла дуже висока. Якщо застосовується модель пласких транзакцій, доведеться наново виконувати все складові транзакції, що підвищує вимоги до обчислювальним ресурсів і віднімає значну частину пропускну здатність системи.

Малюнок 2. Виконання пласкою транзакції серед великої організації.

Вочевидь, що у століття сильно розподілених обчислень необхідно якимось чином проводити декомпозицію пласких транзакцій. Модификация моделі пласких транзакцій, яка зберігає властивість атомарности, але яка б знизила потреба у повторному виконанні дій (т. е. в "переробках"), включає поняття контрольних точок, яку ми обговоримо наступного розділі.

2.2. Контрольні точки

Контрольні точки встановлюються в прикладної програмі у тому, щоб відзначити моменти, починаючи із яких продовжити обчислення у разі виникнення проблем. У ідеалі контрольні точки повинні відповідати частково узгодженим станам (наприклад, після побудови допоміжної таблиці у програмі, які потім використовуватиметься обчислень з участю ще будь-якої таблиці).

Після досягнення черговий контрольної точки в транзакції створюється нове атомарну дію, яке запускається виконання. Лише останні атомарну дію всієї послідовності може виконати фіксацію (COMMIT WORK) транзакції; оператор COMMIT WORK передається всім попереднім атомарным діям, доки всі вона буде зафіксовано. На відміну від моделі многозвенных транзакцій, які ми розглянемо наступного розділі, контрольна точка не призводить до необоротною фіксації, виконаною доти роботи.

Прерывания (ROLL BACK), чи відкоти, транзакції можуть ініціюватися із будь-якої атомарної дії, Не тільки з останнього; хоча у будь-який поставлене час переривання може ініціювати лише діяння, запущена останнім. (Це означає, що й для якогось атомарної дії було досягнуто контрольна точка, то тут для цього дії не можливо, у подальшому ухвалено рішення про відкачуванні.) Відкіт то, можливо зроблено до кожній із попередніх контрольних точок, тому менеджер обробки транзакцій повинен сприймати параметр, який би, аж як саме контрольної точки слід виготовити відкіт (в ідеалі логіка докладання має передбачати визначення контрольної точки, до якої у разі невдачі слід відкотити виконання).

Проводилися дослідження з вивченню застосовності про стійких (persistent) контрольних точок, які фіксуються в дискової або інший довгострокової пам'яті, щоб результати виконання були доступні після системних крахов. Проте Грей і Реутер відзначають, що "не видно поки що ніякої рішення, що можна було б взяти беззастережно". Це навряд чи можна вважати великий проблемою, оскільки дві нові моделі транзакцій - вкладені і многозвенные транзакції - надають схожі можливості тим більше, що формальні визначення цих парадигм набагато краще пророблені й загальноприйняті. Розглянемо спочатку многозвенные транзакції.

2.3. Многозвенные транзакції

Модель многозвенных транзакцій (рис. 3) концептуально подібна моделі контрольних точок, але він передбачає фіксацію частини роботи, зробленою до певного моменту; можливість відкоту зафіксованих дій виключається.

Малюнок 3. Концептуальне уявлення многозвенных транзакцій.

Додаток тим щонайменше залишається може транзакції; т. е. у своїй немає ініціації черговий транзакції, її завершення, ініціації наступній і його завершення тощо. буд. У межах многозвенной транзакції збережено всі необхідні елементи контексту виконання (курсоры баз даних, відкриті файли тощо. буд.), хоча ресурси, які є непотрібними, можна звільняти.

Модель многозвенных транзакцій включає оператор CHAIN WORK - неподільну комбінацію операторів COMMIT WORK і BEGIN WORK, - яка неравноценна послідовному виконання операторів COMMIT WORK і BEGIN WORK окремо. За виконання цих операторів окремо контекст пропадає; деяка інша транзакція може "вклинитися" й змінити значення базі даних, які потрібні до виконання наступного "ланки" многозвенной транзакції, як цієї ланки почне виконуватися. Отже, многозвенные транзакції концептуально еквівалентні транзакциям з контрольними точками з тією відмінністю, що відкіт може проводитися тільки до останньої зафіксованої точки, а чи не до будь-який попередньої контрольної точки.

Обидві моделі транзакцій - многозвенные і з контрольними точками - дозволяють описувати послідовності дій; відмінності стосуються лише можливостей відкоту і стійкості виконаних до заданої точки дій. Остання модель, що її обговоримо, - це модель, що дозволяє описувати не послідовності, а ієрархії субтранзакций.

2.4. Вкладені транзакції

Модель вкладених транзакцій включає поняття головний транзакції, який управляє виконанням всієї ієрархії. У межах ієрархії можуть бути присутні транзакції різних рівнів вкладеності (рис. 4). Концевые вузли ієрархії є плоскі транзакції. Окремі галузі ієрархії може мати різну довжину, т. е. кінцеві транзакції можуть бути на різному "відстані" головного транзакції (деревокореня транзакцій).

Малюнок 4. Структура вкладених транзакцій.

Правила і моделі вкладених транзакцій були вперше розроблено Эллиотом Моссом в 1981 року. У моделі Мосса реальні дії могли проводитися тільки кінцевими субтранзакциями, але Грей і Реутер відзначають, що цього правила обмежує функції вкладення транзакцій що його скасування дає додаткових можливостей розпаралелювання дій над поділюваними об'єктами під час введення абстракції багаторівневих об'єктів.

Мосс сформулював три правила керувати вкладеними транзакціями:

Правило фіксації. Виконання оператора COMMIT WORK у певній субтранзакции робить його результати видимими лише батьківської транзакції. Фактична фіксація субтранзакции відбувається після фіксації всіх його предків до головний транзакції.

Правило переривання (відкоту). Якщо субтранзакция деякого рівня, включаючи головну, відкочується, той самий має зроблено всім її нащадків, незалежно статусу фіксації кожної на локальному рівні.

- Правило видимості. Усі дії, виконані рамках субтранзакции, у її фіксації стають видимими батьківської транзакції. Усі об'єкти, захоплені деякою транзакцией, доступні її нащадкам. Сусідні транзакції (які стосуються одному рівню та мають загального батька) "невеликі" одна одній ані в, ні з іншому сенсі, що дозволяє виконувати їх паралельно.

З властивостей ACID для субтранзакций виконуються властивості атомарности, узгодженості і ізольованості. Але оскільки COMMIT WORK для субтранзакции насправді значить її фіксації до фіксації всієї транзакції, то властивість довговічності не виконується, тому субтранзакции не еквівалентні пласким транзакциям.

Як і інші моделі, вкладені транзакції мають варіації, зокрема модель багаторівневих (multilevel) транзакцій, де субтранзакция ST1 "попередньо фіксує" результати. У цьому нею передбачена компенсирующая субтранзакция, яка може скасувати виконані ST1 дії, якщо з'являється переривання всієї транзакції загалом. Компенсирующие транзакції дозволяють скасовувати результати майже часі; у тому відсутність доводиться застосовувати сценарії відновлення з аналізом часу вироблених змін, навіщо використовуються дорогі оперативні ресурси, щоб забезпечити повернення бази даних в узгоджене стан (наприклад, із застосуванням журналів чи шляхом "зіставлення фрагментів" головоломки-мозаики, щоб визначити, яким має бути узгоджене стан бази даних).

Хоча можна уявити докладання і системи, у яких многозвенные і вкладені транзакції було б корисні, однак лише на початку 1990-х років у комерційних додатках змінюють пласким транзакциям почали надходити інші. Цікаво, втім, відзначити, що з вивченні транзакцій SQL можна знайти деякі ознаки "псевдовложенности", по крайнього заходу у засобах обробки операторів (це у час недоступно розробникам додатків; проте прийнятий у час стандарт SQL3 містить контрольні крапки й, мабуть, до нього ввійдуть оператори управління многозвенными транзакціями).

На рис. 5 показано виконання транзакції SQL. Кожен оператор всередині транзакції, що дає, наприклад, послідовність операторів UPDATE і DELETE, може завершитися успішно чи неуспішно. Навіть якщо його чи кілька операторів завершуються невдачею, транзакція загалом може тривати досить, якщо в логіці тих випадків року передбачено переривання з відкотом в початкова стан. Усі успішно які завершилися до переривання оператори (які у цій моделі можна становити як субтранзакции) скасують, якщо з'являється відкіт всієї транзакції.

Малюнок 5. SQL як псевдовложенных транзакцій.

Розробникам додатків доводилося якось компенсувати недоступність наявних у SQL властивостей псевдовложенности, застосовуючи різні хитрощі для побудови архітектур транзакцій, які відповідають їхніх життєвих потреб, ніж найпростіші плоскі транзакції. Коли над ринком утвердиться стандарт SQL3, й розпочнуть з'являтися сумісні з нею продукти, розробники додатків з урахуванням SQL СУБД зможуть безпосередньо користуватися перевагами нових моделей транзакцій.

3. Encina і DCE

Монітор обробки транзакцій Encina корпорації Transarc можна як комерційний продукт другого покоління, проте він більше розвинений, який відбиває новітні досягнення у цій галузі. Encina включає модель вкладених

Страница 1 из 2 | Следующая страница

Схожі реферати:

Навігація