Documentum - есть ли там понятие "транзакция БД" ?

Pavel Berezin
Дата: 15.07.2011 12:19:23
Набюдаю уже третью команду разработчиков, которые пишут java-код в системе довольно своеобразно. А именно - если к примеру кодят сложную бизнес-операцию, которая к примеру модифицирует несколько объектов (таблиц) в репозитарии, то делают в коде несколько объект.save в разных точках, при этом всё вместе никак не охвачено единой транзакцией.
Т.е. в случаях сбоя такого алгоритма, в БД репозитария появится мусор в виде не полностью модифицированных объектов. Либо, даже если и работает алгорим безглючно, но с учётом распределённости во времени процедуры обновения всех модифицируемых данных, - получается, какоето ненулевое время в репозитарии имеем несогласованные данные (когда один такой алгоритм ещё находится в процессе модификации чего либо, а другие алгоритмы асинхронно взаимодействуют с этими данными).

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

Вопрос: а как вообще по уму в документуме должны кодиться сложные, распределённые во времени транзакции? Чтото не верится, что скольнибудь сложную многопользовательскую систему можно реализовать без begintrans...commit

Поделитесь мыслями чтоли.
Garya
Дата: 15.07.2011 15:58:23
Под "транзакцией" в разных системах подразумеваются разные вещи. В BPM, EAI и DocFlow-системах имеется понятие, которое правильнее называть "длинная транзакция". Такая транзакция не имеет никакого отношения к ACID. Это просто некоторая взаимосвязанная последовательность действий, имеющая начало и конец. Но такая последовательность действий может длиться дни, месяцы и даже годы.

СУБД тоже оперируют "транзакциями", но другого вида - короткими транзакциями. Там тоже имеется последовательность действий, но такая, которая рассматривается как единое целове и не имеет права находиться в БД как "недовыполненная" длительное время. И для таких транзакций ACID - вполне резонные требования.

Каждая операция сохранения промежуточного состояния "длинной транзакции" может (и, наверное, даже должна) осуществляться в короткой ACID-транзакции. Но сама "длинная транзакция" не запускается внутри СУБД-шной транзакции, это просто ни к чему.

Пример длинной транзакции:
1. Поступила заявка потенциального клиента
2. Заявка рассмотрена и произведена оценка
3. Отправлено встречное предложение клиенту
4. Получено подтверждение
...
1000. Заявка исполнена и закрыта.

Между п.3 и п.4 может пройти месяц. Но сохранение в БД каждого из этих пунктов происходит в ACID-транзакции.
Pavel Berezin
Дата: 15.07.2011 17:22:04
ну да - имеется в виду короткая транзакция ессно (которая выполняется одним пользователем единомоментно, и подтвеждается жамканьем Save/Cancel ).

Вот то что наблюдаю, что короткие транзакции не особенно стремятся реализовать (как будто пишут не систему на 500 человек-онлайн, а однопользовательскую БД). Хотелось бы разобраться применительно к документуму, как должно быть по уму (и какой функционал там в этом случае надо использовать).
Partisan M
Дата: 17.07.2011 11:30:52
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, значение которого равно числу успешных сохранений изменений объекта). Другой, тоже обычный при плохом программировании - если одни атрибуты изменились, другие нет.
iscrafm
Дата: 17.07.2011 11:41:25
Partisan M
начальство обычно не понимает, что программирование для Документума занятие сложное, и поручает ему кому попало (наблюдал это в известных фирмах)

зачем же так систему дискредитировать.
Partisan M
Дата: 17.07.2011 11:55:45
iscrafm

Я не "дискредитировал платформу", а сообщил техническую информацию. Зачем - тоже объяснил: недостаточная квалификация разработчиков это обстоятельство, которое надо иметь ввиду, поскольку оно может нанести большой ущерб заказчику. Дискредитируют платформу "жабабыдлокодеры" и их начальники, которые успешно руководят тем, в чём ничего не смыслят. В общем, я описал как оно есть.
Pavel Berezin
Дата: 17.07.2011 17:01:50
Спасибо за развёрнутый ответ

автор
- самая слабая - метод fetch () в классе IDfPersistentObject. Не обеспечивает закрепления объекта за одним пользователем (другие могут менять), а только получение последней версии.
- затем выписка (checkout(), checkin(), save(), savelock()) - это блокировка для редактирования одним пользователем
Partisan M,


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

автор
- явные транзакции, то есть запрограммированные в приложении. Они помогают добавить проверку согласованности атрибутов перед сохранинием. Осуществляются с помощью beginTransaction () в классе IDfSessionManager (посмотреть также описание "сессий" и при знании Java - документацию JavaDoc по DFC по этим классам). То, что в Документуме называется транзакциями - явные и неявные, осуществляются Content Server-ом, то есть на уровне хранилища.


Вот это собственно и интересует - откопал в документации эти begintransaction, хотелось бы уточнить, там есть какието принципиальные технические ограничения на использование этого метода? Вот если к примеру дорабатываем вебморду ведения записи dm_user'a (родная уж слишком убогая) - и нужно по нажатию Save единой транзакцией поменять сразу объекты dm_user, его ACL, и несколько dm_group (например реализовать его перемещение по оргструктуре предприятия, построенной на группах) - будет ли модификация всех этиъ объектов производиться единым commit'ом ? И будет-ли транзакция изолирована от остальных (т.е. параллельно работающие процессы не подхватят ли "грязные" данные от этой транзакции)?
Pavel Berezin
Дата: 17.07.2011 17:04:48
автор
Поэтому желательно самому что-то знать. Как минимум, надо прочитать книгу Content Server Fundamentals, где написано и про транзакции. По возможности надо самому посетить хотя бы курсы "Технические основы Документума".


Пока увы хватает на чтение отдельных PDF-ов, просто это не единственная система на сопровождении (и не самая главная).

А что порекомендуете из курсов, и где (если вообще есть выбор) более вменяемо преподают? Есть потребность выпестовать своих специалистов, но пока процесс идёт трудно.
iscrafm
Дата: 18.07.2011 21:00:43
Pavel Berezin,

какого плана у вас система под управлением Документума? судя по тому, что масса людей имеют возможность редактировать один документ, то это типа общественной библиотеки, но не только для читателей и писателей? Или вы документум применяете в качестве CSV и им подобным?
Pavel Berezin
Дата: 19.07.2011 11:44:55
iscrafm,

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