| Pavel Berezin |
|---|
Причём, когда разговариваешь с разработчиками про транзакции, делают удивлённое лицо - так мол нельзя, локументум не ERP а хранилище данных, и проч.отговорки.
Документщиков так учат кодить впринципе? Или они чегото не договаривают? |
Верить российским разработчикам Документума нельзя ни в чём. Могут и врать, и не знать элементарное. Не следует верить и их начальникам, потому что они пересказывают глупости разработчиков. Это самое важное, что надо знать о Документуме. Поэтому желательно самому что-то знать. Как минимум, надо прочитать книгу Content Server Fundamentals, где написано и про транзакции. По возможности надо самому посетить хотя бы курсы "Технические основы Документума".
Разработчиков не учат в достаточной степени - начальство обычно не понимает, что программирование для Документума занятие сложное, и поручает ему кому попало (наблюдал это в известных фирмах). Есть курсы, и они полезные, но там объясняют самые основы для начала работы, дальше надо изучать самостоятельно. Но от разработчиков желательно, чтобы они представили справки о посещениии курсов и ешё лучше - сертификаты.
Транзакции в Документуме есть, и длинные и короткие (только они так не называются). Длинные реализуются как жизненные циклы (lifecycle). Жизненный цикл это последовательность состояний объекта, состояние - согласованный набор атрибутов (параметров). Контроль согласованности осуществляется: как без программирования (заданием условий вхождения в состояние), так и с ним (отдельной процедурой жизненного цикла, написанной на Java или языке DocBasic).
Вас интересовали "короткие транзакции", которые так не называются. Они связаны с блокировками (lock) объектов. Есть нескольуо уровней блокировки, на самом строгом она осуществляется и на уровне базы данных. Эти уровни:
- самая слабая - метод fetch () в классе IDfPersistentObject. Не обеспечивает закрепления объекта за одним пользователем (другие могут менять), а только получение последней версии.
- затем выписка (checkout(), checkin(), save(), savelock()) - это блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных)
- явные транзакции, то есть запрограммированные в приложении. Они помогают добавить проверку согласованности атрибутов перед сохранинием. Осуществляются с помощью beginTransaction () в классе IDfSessionManager (посмотреть также описание "сессий" и при знании Java - документацию JavaDoc по DFC по этим классам). То, что в Документуме называется транзакциями - явные и неявные, осуществляются Content Server-ом, то есть на уровне хранилища.
- блокировка на уровне СУБД (самая строгая), нужна редко, происходит если вызвать метод lock () или lockEx () класса IDfPersistentObject. Это предотвращает неудачу записи изменённого объекта если он во время редактирования изменялся ещё и автоматически Документумом. Итак, для "транзакции БД" нужно вызывать метод lockEх() внутри транзакции, начатой по beginTransaction(). Это бывает нужно редко (мне ни разу не понадобилось), но разработчики должны разбираться в методах блокировки и правильно применять нужные.
Обычный признак неправильного применения блокировок - исключение вида version mismatch - в хранилище уже оказалась более новая версия объекта (определяется по автоматически назначаемому атрибуту i_vstamp, значение которого равно числу успешных сохранений изменений объекта). Другой, тоже обычный при плохом программировании - если одни атрибуты изменились, другие нет.