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

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

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

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

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

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

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

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