Оптимистический подход
Основная идея оптимистических протоколов − максимизировать объем выполняемой работы. Эти протоколы дают шанс работать всем транзакциям, но разрешают благополучно завершиться только тем из них, чье завершение не влечет нарушения целостности базы.
С точки зрения менеджера управления транзакций при использовании оптимистического протокола выполнение транзакции делится на три концептуальные фазы: чтение, проверка, запись. В течение фазы чтения транзакция работает параллельно с другими транзакциями без каких-либо ограничений, но все измененные данные записываются в личную рабочую память транзакции, а не в базу. Когда транзакция завершает свою работу, менеджер инициирует фазу проверки транзакции на наличие конфликтов с другими транзакциями. Если проверка окончилась удачно (т.е. конфликтов не обнаружено), то сделанные транзакцией изменения переносятся в базу и становятся видимыми другим транзакциям. В противном случае, сама транзакция или конфликтующие с ней транзакции завершаются анормально (т.е. сделанные изменения забываются).
По типу проверки оптимистические протоколы делятся на «вперед смотрящие» (forward validation) [79] и «назад смотрящие» (backward validation) [79]. Различие состоит в выборе множества транзакций для проверки на наличие конфликтов при завершении транзакции Т0. Протоколы из первой группы используют в качестве такого множества − все еще не завершенные транзакции (и соответственно анормально завершают все те из них, которые конфликтуют с Т0 либо саму Т0). А «назад смотрящие» проводят проверку по отношению ко всем нормально завершившимся транзакциям и в случае конфликта анормально завершают только Т0.
Сравнение подходов
Основным недостатком пессимистического подхода являются простои во время тупиков и растрата машинных ресурсов на их обнаружение и разрешение.
Оптимистический подход бесполезно тратит машинные ресурсы на работу транзакций, которые позже будут анормально завершены из-за возникновения конфликтов, а также на работу на стадии проверки при завершении каждой транзакции.
Экспериментальные результаты показывают, что в случае классических СУБД пессимистический подход обычно показывает лучшие результаты [79]. Поэтому в большинстве современных промышленных СУБД используются разновидности пессимистических протоколов.
4.9.3 Протоколы управления транзакциями в субд реального времени
В отличие от классических СУБД в системе реального времени с каждой транзакцией ассоциируется директивный срок, т.е. момент времени, до которого транзакция должна быть завершена.
По типу директивных сроков СУБДРВ можно разделить на три основные группы: с жесткими, крепкими и мягкими директивными сроками [79]. В системе с жесткими директивными сроками любая задержка эквивалентна катастрофе, а с крепкими и мягкими директивными сроками только понижает производительность системы. Различие последних состоит в том, что в системе с крепкими директивными сроками транзакция, пропустившая свой директивный срок, выкидывается из системы, а в системе с мягкими директивными сроками такая транзакция просто становится менее значимой, но все еще может быть с пользой завершена.
Формально различие между типами директивных сроков можно описать при помощи функции полезности транзакции в зависимости от времени завершения. На рисунке 4.9.1 показан вид этой функции для всех трех типов систем.
По достижении директивного срока в системах первого типа транзакция становится «вредной», т.е. имеет отрицательную полезность. Если же директивные сроки крепкие, то транзакция просто становится бесполезной, но не «вредной». А в системах с мягкими директивными сроками полезность транзакции начинает постепенно уменьшаться с увеличением времени опоздания.
Рисунок 4.9.1 – Функция полезности для систем с мягкими, крепкими и жесткими директивными сроками
Еще одним важным отличием от случая классических СУБД является использование других критериев производительности. В классических СУБД производительность обычно измеряется как среднее число завершившихся транзакций в единицу времени, а в системе, работающей в реальном времени, на первый план выходят другие параметры − количество транзакций, пропустивших свои директивные сроки, среднее опоздание транзакций и т. п. Производительность же обычно меряют при помощи величины, которая зависит от нескольких таких параметров.
Способы вычисления этих величин сильно отличаются для разных типов СУБД реального времени. Так, например, в системах с крепкими директивными сроками среднее время опоздания транзакций не играет никакой роли, в то время как в системах с мягкими директивными сроками этот параметр довольно полезен [79].
Отличие критериев производительности, используемых в базах данных реального времени, от тех, что используются в классических СУБД, является основной причиной далеко не лучшей производительности при применении в системах реального времени классических протоколов управления транзакциями. Это, очевидным образом, влечет необходимость использования в таких системах других протоколов, которые лучше справляются со специфическими требованиями систем реального времени.
Используемые в СУБД реального времени протоколы должны использовать приоритеты транзакций, основанные на их директивных сроках, при разрешении конфликтов для того, чтобы гарантировать, что транзакция с большим приоритетом не будет задержана транзакцией с меньшим приоритетом. Это требование совершенно не учитывается в классических протоколах и это является одной из основных причин их неудовлетворительной производительности.
В течение последних 10 лет для систем реального времени был предложен ряд специфических протоколов с улучшенными характеристиками для систем реального времени. Среди них есть как модификации классических пессимистических и оптимистических протоколов [79], так совершенно новые, созданные специально для систем реального времени, протоколы [79].