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

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

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

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

Диспетчеризация транзакций

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

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

Было изучено множество различных политик назначения приоритетов [79] − как для назначения приоритетов различным классам транзакций, так и транзакциям внутри одного класса. Рассмотрим для примера несколько вариантов политик назначения приоритетов различным классам транзакций:

· оба класса транзакций имеют одинаковый приоритет;

· пользовательские транзакции получают больший приоритет;

· пользовательские транзакции получают меньший приоритет;

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

Поскольку для корректного завершения транзакции необходимо, чтобы использованные ей данные были временно целостными, то полезно ввести понятие директивного срока данных (data-deadline). Директивный срок данных транзакции − это момент времени, по истечении которого временная целостность использованных данных будет нарушена. Естественно, что дальнейшее выполнение этой транзакции будет бесполезной тратой ресурсов, так как она все равно не сможет быть нормально завершена. Следовательно, учет информации о директивных сроках данных транзакций может помочь повысить производительность системы.

Директивный срок данных транзакции T вычисляется согласно следующему алгоритму:

· Старт транзакции T^{data_deadline}_T ^{= deadline} _T.

· Чтение объекта (x, x_{timestamp ,} x_avi)

. (4.9.3)

Для того чтобы извлечь реальную пользу из директивных сроков данных, эту информацию можно использовать для назначения приоритетов транзакций. В общем виде несложная формула вычисления приоритета транзакции выглядит так (0<a<1):

priority_T = a * data_deadline_T +(1– a)* deadline_T. (4.9.4)

В зависимости от значения a можно выделить следующие характерные политики распределения транзакций:

· По ближайшему директивному сроку: a=0.

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

· По ближайшему директивному сроку данных: a=1.

Этот алгоритм учитывает только data-deadline транзакции. Согласно этому алгоритму транзакция T₁ с большим директивным сроком, но с маленьким data-deadline получит больший приоритет, чем транзакция T₂ с меньшим директивным сроком. Следовательно, транзакция T₂ может не успеть завершиться по причине пропуска директивный срока, тогда как, если T₂ назначить больший приоритет, то и T₁ и T₂ могут успеть завершиться.

· Гибридный подход:

. (4.9.5)

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

· Пропорционально выполненной работе: a – процент сделанной транзакцией работы.

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

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