Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Драйвери JDBC




Всього існує чотири категорії драйверів JDBC.

Тип 1 - драйвери, які реалізують інтерфейс JDBC поверх іншого інтерфейса, наприклад ODBC; Ця категорія драйверів часто залежить від конкретних платформ, тому є проблемною при перенесені.

Тип 2 - драйвери, частково написані на Java, а частково - в вигляді бінарного системно-залежного коду; в них, як правило, використовуються бінарні бібліотеки конккретних платформ бинарные, що забезпечують зв’язок з БД на низькому рівні.

Тип 3 - драйвери, реалізовані повністю на Java і взаємодіючі безпосередньо з сервером проміжного рівня при допозі незалежного від конкретної БД протокола; цей сервер передає клиєнтські запити джерелу даних.

Тип 4 - драйвери, реалізовані повністю на Java і взаємодіючі безпосередньо з БД через мережевий протокол.

- Інтерфейс DB-LIB (бібліотек баз даних);

Інтерфейс DB-LIB являє собою спеціально призначений для SQL інтерфейс прикладних програм.

 

 

Лекція 12. Транзакції. Паралельне виконання транзакцій.

Визначення транзакції. Виконання. Відкат. Адміністрування.Журналізація. Властивості транзакції. Види транзакцій. Управління транзакціями в мовах програмування. Керування паралельністю. Проблеми паралелізму. Проблема загубленого відновлення. Проблема залежності від нефіксованих результатів. Проблема неузгодженої обробки. Блокування. Рівні ізолювання транзакцій. Використання протоколу двох фазного блокування для усунення проблем.

12.1. Визначення транзакції. Виконання. Відкат.

Транзакція – це неподільна, з точки зору СУБД, послідовність операцій по маніпулюванню даними.

Транзакція є логічною одиницею роботи, виконуваної в базі даних. Вона може бути представлена окремою програмою, бути частиною алгоритму програми або навіть окремою командою (наприклад, командою INSERT або UPDATE мови SQL) і включати довільну кількість операцій, виконуваних у базі даних.

 

Будь-яка транзакція завершується одним із двох можливих способів.

У випадку успішного завершення результати транзакції фіксуються (commit) у базі даних, і остання переходить у новий погоджений(цілісний) стан.

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

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

Слід зазначити, що скасована транзакція може бути ще раз запущена пізніше і, у залежності від причин попередньої невдачі, цілком успішно завершена і зафіксована в базі даних.

Таким чином підсистема транзакцій є механізмом забезпечення цілісності БД.

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

12.2. Властивості транзакції. Види транзакцій.

Кожна з транзакцій повинна Існують володіти наступними властивостями:

· Атомарність. Це властивість типу "всі або нічого". Будь-яка транзакція являє собою неподільну одиницю роботи, що може бути або виконана вся цілком, або не виконана зовсім.

· Погодженість. Кожна транзакція повинна переводити базу даних з одного погодженого стану в інший погоджений стан.

· Ізольованість. Усі транзакції виконуються незалежно одна від іншої. Іншими словами, проміжні результати незавершеної транзакції не повинні бути доступні іншими транзакціям.

· Тривалість. Результати успішно завершеної (зафіксованої) транзакції повинні зберігатися в базі даних постійно і не повинні бути загублені в результаті наступних можливих збоїв.

 

Загалом, транзакції поділяються на пишучі та читаючі.

12.3. Блокування. Рівні ізолювання транзакцій.

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

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

12.4. Управління транзакціями в мовах програмування.

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

Тому повинен існувати метод, що дозволяє вказувати границі кожної транзакції ззовні, з боку користувача. У більшості мов маніпулювання даними для вказівки границь окремих транзакцій використовуються оператори BEGIN TRANSACTION, COMMIT і ROLLBACK (або їхні еквіваленти).

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

Тому необхідно старатись, щоб пишучі транзакції були короткими.

Керування паралельністю. Проблеми паралелізму.

Найважливішою метою створення баз даних є організація паралельного доступу багатьох користувачів до спільно використовуваних даних. Забезпечити паралельний доступ нескладно, якщо всі користувачі будуть тільки читати дані, поміщені в базу. У цьому випадку робота кожного з них не робить ніякого впливу на роботу інших користувачів. Однак, якщо два або більше користувачі одночасно звертаються до бази даних і хоча б один з них має на меті обновити збережену в базі інформацію, можливий взаємний вплив процесів один на одного, здатний привести БД у суперечливий стан.

При цьому можливі наступні потенційні проблеми при виконанні транзакцій:

- проблема загубленого відновлення,

- проблему залежності від нефіксованих результатів

проблему неузгодженої обробки.

Проблема загубленого відновлення.

Результати успішно завершеної операції відновлення однієї транзакції можуть бути перекриті результатами виконання іншої транзакції. Ця аномалія відома як проблема загубленого відновлення.

Її суть ілюструється наступним прикладом:

Час Транзакція Т1 Транзакція Т2, Поле balx
t1 begin transaction    
t2 read(bal(t2)) begin transaction  
t3 balT1(t3) = bal(t2) + 100 Read(bal(t3))  
t4 write (balT1(3)) bal(t4) = balT2(t3)- 10  
t5 commit Write (balT2(t4))  
t6   commit  

У цьому прикладі транзакція T1 виконується паралельно з транзакцією Т2. Транзакція Т1 виконує занесення 100грн. на рахунок bal, а Т2 знімає 10грн. з цього ж рахунку, на якому з початку знаходиться 100грн.

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

Транзакція Т1 починаються в момент часу t1, а Т2 в момент часу t2 . Кожна з них зчитує початкове значення суми на рахунку bal, рівне 100грн. Потім транзакція Т1 збільшує суму на 100грн. і записує результат, рівним 200грн., у базу даних — на рахунок bal(t4). Тим часом транзакція T2 зменшує значення своєї копії початкової суми на рахунку і записує отримане значення, рівним 90грн. у базу даних на рахунок bal(t5)., перекриваючи результат попереднього відновлення. У результаті з рахунку "зникає" 100грн.

Уникнути втрати результатів виконання транзакції Т1 можна, заборонивши транзакції t2 зчитувати вихідне значення на рахунку bal аж до завершення виконання транзакції Т1.

Проблема залежності від нефіксованих результатів.

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

Час Транзакція Т3 Транзакція T4 Поле balх
t1   begin transaction  
t2   read(balx)  
  bal(t3) = bal(t2) + 100  
t4 begin transaction write (bal(t3))  
t5 Read(bal(t5))    
t6 bal(6) = bal(t5) -10 rollback  
t7 Write (bal(t6))    
t8 commit    

У прикладі транзакція Т4 збільшує значення суми на рахунку bal до 200грн., після чого виконання транзакції скасовується, з відновленням початкового значення на рахунку bal, рівним 100грн.

Однак до цього моменту транзакція Т3 уже встигла зчитати змінене значення рахунка bal =200грн. і використала саме це значення при виконанні операції зняття грошей з рахунку, після чого зафіксувала в базі даних невірний результат 190грн. замість 90грн.

 

Причина виконання відкату транзакції Т4 несуттєва – наприклад при її виконанні була виявлена деяка помилка (введено невірний номер рахунку).

Джерелом помилки є припущення транзакцією Т3, що виконана в транзакції Т4 зміна буде успішно зафіксована в базі даних, хоча насправді мав місце відкат транзакції.

Проблему можна усунути, заборонивши транзакції Т3 зчитувати значення рахунку bal доти, поки транзакція Т4 не буде або зафіксована, або скасована.

Проблема неузгодженої обробки.

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

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

Час Транзакція Т5 Транзакція Т6 Поле bal1 Поле bal2 Поле bal3 Поле sum
t1   begin transaction        
t2 begin transaction sum = 0        
t3 read(bal1(t3)) read (bal(t3))        
t4 bal1(t4) = bal1(t3) – 10 sum = sum + bal(t3)        
t5 write (bal1(t4)) read(bal2(t5))        
t6 read(bal3(t6)) sum = sum + bal2(t5)        
t7 Bal3(t7) = bal3(t6) + 10          
t8 write (bal3(t7))          
t9 commit read (bal3(t9))        
t10   sum = sum + bal3(t9)        
t11   commit        

Транзакція Т6 обчислює суму залишків на рахунках bal1= 100грн., bal2= 50грн. і bal3= 25грн.

Паралельно з Т6 транзакція Т5 здійснює переказ 10грн. з рахунку bal1 на рахунок bа13.

В результаті значення суми, отримане транзакцією Т6 є невірним: 185грн. замість 175грн.

Ця проблема може бути усунута шляхом, заборони транзакції Т6 зчитувати значення на рахунках bal1 і bal3 доти, поки транзакція Т5 не зафіксує виконані нею відновлення.




Поделиться с друзьями:


Дата добавления: 2014-10-15; Просмотров: 468; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.034 сек.