Все таки решил до конца разобраться с работой процесса транзакции на TPS-драйвере.
Сначала некоторые уточнения и дополнения к предыдущим моим письмам по этой теме.
Во время выполнения оператора COMMIT() физическая запись данных в файлы производится поочередно в порядке, обратном порядку их задания в операторе LOGOUT().
Все это происходит в четыре этапа:
Создается TCF-файл и в него записывается информация о таблицах, участвующих в транзакции. Данные, накопленные в транзакционном буфере, записываются во ВСЕ таблицы в резервные(временные) страницы. Некоторые особенности этих страниц будут описаны ниже. Происходит модификация TCF-файла. В чем она заключается — не разбирался, но это — единственная модификация TCF-файла в рамках транзакции. Очевидно, что при этом записывается информация об окончании этапа N2.
Записи из резервных страниц во ВСЕХ таблицах переписываются в нормальные(постоянные) страницы. Резервные страницы при этом не удаляются. Это произойдет лишь во время закрытия таблиц оператором CLOSE().
Особенности резервных(временных) страниц, в случае прерывания выполнения оператора COMMIT():
до завершения этапа N3, резервные страницы НИКАК себя не проявляют в дальнейшем. после завершения этапа N3 и до завершения этапа N4:
если до транзакции таблица была пустой, то ВСЕ записи в резервных страницах нормально читаются ВСЕМИ операторами типа GET/NEXT/PREVIOUS; если в таблице уже были записи, то резервные страницы не видны. если до транзакции таблица была пустой, то при первом-же выполнении оператора модификации типа ADD/PUT/DELETE записи из резервных страниц переводятся в нормальные а сами резервные страницы удаляются.
при закрытии таблицы оператором CLOSE резервные страницы просто удаляются.
Автоматического восстановления таблиц НЕ ПРОИСХОДИТ!!!
если выполнение COMMIT() прервалось во время выполнения этапа N4, то ВСЕ таблицы открываются нормально, но резервные страницы остаются на месте со всеми последствиями, описанными выше. Оператор CLOSE() удаляет резервные страницы. При этом модификация одной таблицы НЕ ЗАТРАГИВАЕТ другие таблицы, которые участвовали в транзакции! Таким образом, если во время этапа N4 некоторые таблицы уже были полностью обработаны, то их «ОТКАТА» НЕ БУДЕТ НИКОГДА!
Вот так!!!
В транзакции участвовало несколько файлов, а их восстановление происходит РАЗДЕЛЬНО! Т.е., НИКАКОГО СОХРАНЕНИЯ ЛОГИЧЕСКОЙ ЦЕЛОСТНОСТИ ДАННЫХ транзакция НЕ ОБЕСПЕЧИВАЕТ!
Хотя, нет, стоп! Не столь категорично!
Логическая целостность обеспечивается на все 100% ТОЛЬКО ДО выполнения оператора COMMIT(). Крах ВО ВРЕМЯ выполнения оператора COMMIT() практически не страшен до завершения этапа N3. Крах ВО ВРЕМЯ этапа N4, В БОЛЬШИНСТВЕ случаев, приводит к НАРУШЕНИЮ ЛОГИЧЕСКОЙ ЦЕЛОСТНОСТИ данных!
Короче, остается лишь уповать на надежность оборудования в том коротком промежутке времени, когда выполняется этап N4 оператора COMMIT()!
И, соответственно, стараться делать обьем транзакций минимальным. Хотя, как в таком случае соблюсти логическую целостность?!
И еще остается вопрос — на кой нужен TCF-файл!?
Если он реально НЕ ОБЕСПЕЧИВАЕТ связное восстановление таблиц, участвовавших в транзакции!
Ау, коллеги, «близкие» к SV!
Возможно разработчики из SV опровергнут мои выводы (очень хотелось-бы!), или, хотя-бы, дадут некоторые разъяснения!?
Кстати! Во время открытия таблицы, которая участвовала в прерванной транзакции, определяется факт наличия незавершенной транзакции!
Но никаких действий по ее «откату» НЕ ПРОИЗВОДИТСЯ!
Почему — не стал вникать — уж слишком там «наворочено». Поэтому хотелось-бы и по этому поводу получить разъяснения от разработчиков SV!