Выбор версии непрерывного объекта

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

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

Рассмотрим следующий пример. Допустим, что множество непрерывных данных состоит из двух объектов a (версии (a₀,0,20) и (a₁,10,20)) и b (версия (b₀,0,20)) и пусть интервал относительной корректности для этого множества R_rvi=9. Транзакция T начинается в момент времени t=10 и завершается к t=20. При этом T использует и a, и b. На время работы T существует две корректных версии элемента a-a₀ и a₁. Однако, если транзакция воспользуется a₁, то она не сможет быть завершена из-за того, что использованные данные не будут относительно корректными. При использовании же более старого значения (a₀) критерий относительной корректности не будет нарушен.

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

4.9.8 Как бороться с перегрузкой системы из-за обилия сенсорных транзакций?

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

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

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

4.9.9 Когда обновлять выводимые объекты?

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

Поскольку изменение базового объекта может повлечь изменение нескольких выводимых объектов, а также, поскольку значение выводимого объекта может зависеть от значений нескольких базовых объектов, то непосредственное обновление выводимого объекта d всякий раз, как меняется значение базовых элементов, из которых d выводится, может повлечь растрату ресурсов на выполнение лишней работы. Если же обновлять выводимый элемент данных слишком редко, то возможно, что в течение какого-то времени в системе вообще не будет корректного на данный момент значения выводимого элемента. Разумное промежуточное решение − использование политики «изменения по необходимости». Однако недостаток этого подхода − запоздалые изменения. Другое решение, согласно которому изменение значения выводимого объекта запрещается чаще, чем через определенные промежутки времени, приводит к уменьшению нагрузки.

Поскольку изменение состояния одного базового объекта может повлечь обновление сразу нескольких выводимых, то существует две альтернативы. Либо на каждое необходимое обновление порождается отдельная транзакция, либо все необходимые изменения делаются от лица одной транзакции. Недостатком первого варианта является возможное появление значительного числа дополнительных транзакций и, соответственно, повышение нагрузки на менеджер транзакций. С другой стороны, блокировки на эти объекты данных освобождаются раньше, чем при использовании второго варианта. Для уменьшения продолжительности времени блокирования элементов данных при использовании второго подхода можно разрешить снятие блокировок с элементов сразу после завершения их обновления при условии, что модифицируемые объекты не связаны между собой. Иными словами, в силу семантики таких транзакций возможно ослабление «атомарности» и «изолированности» свойств транзакции, в то время как эти свойства сохраняются для каждой операции изменения состояния отдельного выводимого объекта.

4.9.10 Как понизить количество анормальных завершений?

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

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

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