Журнал Redo
В реализации CU-объектов, даже если возникает конфликт, высокоуровневая семантика может позволить продолжить работу, если имеется возможность гарантировать, что база данных останется в согласованном состоянии. Для порождения согласованного вида базы данных транзакция, испытывающая конфликт, должна интегрировать изменения других транзакций со своими собственными изменениями.
Однако повторное проигрывание операций может потерпеть неудачу, если другая транзакция зафиксирует изменение, делающее недействительной одну и повторно выполняемых операций. Если операция CU-объекта не может быть успешно воспроизведена, это связано с действительным конфликтом согласованности, и транзакция оказывается неспособной к фиксации. Это происходит вследствие того, что при обнаружении физического конфликта воспроизводятся только операции, которые изначально были успешно выполнены. Например, предположим, что транзакция Tl пытается удалить последнее вхождение объекта X из CuBag. Может случиться так, что первой свое удаление X зафиксирует другая транзакция T2. Когда Tl пытается зафиксироваться, она испытывает физический конфликт, который старается разрешить. Tl обновляет свое представление CuBag и повторно выполняет операции. Повторная попытка удаления X потерпит неудачу, поскольку X уже не содержится в CuBag, и, следовательно, попытка фиксации провалится.
Чтобы обеспечить возможность повторного выполнения операций при обнаружении физического конфликта, можно реализовать журнал redo для фиксации информации об изменения, выполненных над некоторыми CU-объектами. Журнал redo аналогичен "намерениям", описанным в []. Однако в дополнение к фиксации изменений CU-объекта журнал redo может также содержать результаты операций чтения. Это делается для поддержки таких CU-объектов, как CuAccount и CuHashDirectory, для которых операции чтения должны быть повторяемыми, поскольку на основе прочитанного значения может быть выполнена сложная операция.
