Сравнение подходов

Традиционно протоколы управления транзакциями различаются по двум критериям: время обнаружения конфликтов и способ их обнаружения. Согласно этим критериям пессимистические и оптимистические протоколы представляют собой две крайности.

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

Оба способа разрешения конфликтов имеют свои недостатки. Блокирование приводит к консервированию ресурсов, а рестарты вызывают их растрату.

В системах реального времени протокол управления транзакциями должен работать с большим количеством анормально завершающихся транзакций. И если для оптимистических протоколов это знакомая ситуация, то для пессимистических протоколов рестарты являются новым ограничением.

Слабым местом пессимистического протокола являются также простои транзакций в ожидании получения блокировки на какой-либо ресурс. Такие простои повышают вероятность пропуска директивного срока. При этом транзакция, которая держала блокировку на нужный ресурс, также может пропустить свой директивный срок − из-за того, что он слишком близок или из-за необходимости ждать получения блокировок на другие ресурсы. Тем самым возможно, что все транзакции не успеют завершиться к своим директивным срокам.

Оптимистические протоколы не блокируют ресурсы и не вызывают простоев транзакций, что несомненно является плюсом для систем реального времени. Обратная сторона медали − растрата ресурсов на параллельную работу конфликтующих транзакций, из которых только часть в принципе может завершиться. Кроме того, необходимо отметить, что фаза проверки может быть довольно трудоемкой и это особенно заметно, если сами транзакции очень коротки.

Сравнительный анализ этих двух подходов для модели простых транзакций в системах управления базами данных реального времени с мягкими и крепкими директивными сроками, с ограниченным числом ресурсов и неограниченным, показывает, что в большинстве ситуаций оптимистический подход превосходит пессимистический [79]. Однако в связи с огромным количеством систем реального времени со специфическими требованиями не существует лучшего протокола для всех случаев, и бывают ситуации, когда пессимистический протокол показывает лучшие результаты.

4.9.4 Системы с устаревшими данными

В предыдущем разделе мы рассматривали системы, в которых только транзакции имеют временные ограничения. Однако в системах реального времени зачастую и сами данные могут иметь временную природу [79]. Например, для работы системы автопилота необходимо использовать информацию о силе и направлении ветра, а эта информация меняется непрерывно и очень быстро устаревает. Необходимость работы с устаревающими данными порождает новые проблемы.

В СУБД реального времени объекты данных делятся на два типа: дискретные и непрерывные. Дискретные данные − это «обычные» данные в смысле классических СУБД, т.е. данные, которые не связаны с реальным временем.

Непрерывные данные − это данные, связанные с внешними объектами, состояние которых непрерывно меняется во времени. Естественно, что состояние непрерывного объекта данных отображается в СУБД как дискретно обновляемая величина. Эта величина отражает состояние объекта на определенный момент времени в прошлом и с течением времени может все более отличаться от текущего состояния объекта. Например, если для расчета траектории самолета использовать данные о ветре часовой давности, то полученные результаты не будут соответствовать действительности.

Формально непрерывный объект данных можно описать при помощи следующей тройки (d_value, d_timestamp, d_avi), где d_value − состояние объекта d на момент времени d_timestamp и d_avi − это длина интервала, в течение которого это состояние можно считать корректным. Этот интервал называется интервалом абсолютной корректности элемента данных.

Непрерывными являются не только те элементы данных, которые непосредственно связаны с внешними объектами, но также и те элементы данных, значение которых зависит от других непрерывных объектов. Такие объекты называются соответственно базовыми и выведенными.

Все изменения состояния базы данных выполняются от имени транзакций. Это касается и изменений состояний непрерывных элементов данных. По типу изменяемых данных транзакции подразделяются на следующие классы:

Сенсорные − это транзакции, которые модифицируют базовые объекты. Такие транзакции обычно выполняются периодически и не работают с дискретными элементами данных.

Порожденные − это транзакции, которые модифицируют состояние выведенных объектов. Такие транзакции порождаются в результате изменений тех непрерывных объектов, из которых выводится модифицируемый объект.

Пользовательские − это все остальные транзакции. Они не могут изменять никакие непрерывные объекты, но могут их читать.

Сенсорные и порожденные транзакции обычно имеют крепкие директивные сроки. Это естественное решение − с одной стороны, бессмысленно завершать работу по обновлению состояния объекта, зная, что оно уже не корректно, с другой − если обновить состояние не удалось вовремя, то само по себе это не фатально.