Вопрос о распределении меток времени в оптимизированном параллельном управлении?
Есть статья о введении MVOCC (MVCC + Optimized Concurrent Control)
3.2 Оптимистическое управление параллелизмом (MVOCC)
Следующий протокол основан на схеме оптимистического управления параллелизмом (OCC), предложенной в 1981 году [26]. Мотивация OCC заключается в том, что СУБД предполагает, что транзакции вряд ли будут конфликтовать, и, следовательно, транзакция не должна получать блокировки на кортежи, когда она читает или обновляет их. Это уменьшает количество времени, в течение которого транзакция удерживает блокировки. Существуют изменения в исходном протоколе OCC, чтобы адаптировать его для мультиверинга [27]. Прежде всего, СУБД не поддерживает частную рабочую область для транзакций, поскольку информация о версиях кортежей уже запрещает транзакциям читать или обновлять версии, которые не должны быть им видны.
Протокол MVOCC разделяет транзакцию на три этапа. Когда транзакция начинается, она находится в фазе чтения. Именно здесь транзакция вызывает операции чтения и обновления в базе данных. Подобно MVTO, для выполнения операции чтения с кортежом A СУБД сначала ищет видимую версию Ax на основе полей begin-ts и end-ts. T может обновлять версию Ax, если ее блокировка записи не получена. Если в версии с несколькими версиями транзакция обновляет версию Bx, то СУБД создает версию Bx+1 с ее txn-id, установленным в Tid.
Когда транзакция инструктирует СУБД, что она хочет зафиксировать, она затем входит в фазу проверки. Сначала СУБД назначает транзакции другую метку времени (Tcommit) для определения порядка сериализации транзакций. Затем СУБД определяет, были ли кортежи в наборе чтения транзакции обновлены транзакцией, которая уже зафиксирована. Если транзакция проходит эти проверки, она переходит в фазу записи, где СУБД устанавливает все новые версии и устанавливает их начальные значения в Tcommit и конечные значения в INF.
Транзакции могут обновлять только последнюю версию кортежа. Но транзакция не может прочитать новую версию, пока другая транзакция, которая ее создала, не зафиксирует. Транзакция, которая читает устаревшую версию, обнаружит, что она должна прерваться на этапе проверки.
Поэтому мой вопрос заключается в том, зачем выделять вторую временную метку в качестве ее временной отметки, а не в качестве ее первой? В чем преимущество выделения второго?