Partisan MВяжется.конечно, Ваше утверждение "я знаю документум" и 10985752 корелируют с коэффициентом -1.

Что-то не увидел в каком месте состояние ЖЦ является согласованым набором атрибутов. Состояния ЖЦ в документуме это всего-лишь способ сделать некоторые изменения в СУБД/контенте/etc при наступлении события "у документа изменилось состояние ЖЦ", ни о какой согласованности при этом говорить нельзя (т.е. если у документа такое состояние ЖЦ, то значит у него значения определенных атрибутов соответствуют этому состоянию) - процедура, переводящая документ в новое состояние отработала - все, с документом могут дальше происходить какие-угодно изменения. До DFC6 жизненные циклы были одной из возможностью сделать кастомизацию для объектов без кастомного TBO, после появления аспектов и эскалации привилегий в DFC6 жизненые циклы - просто лишняя сущность.

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




Если запрос не обновил ни одной строки (т.е. в базе нет совпадений для пары (r_object_id, i_vstamp)), то контент выкидывает клиенту ошибку DM_OBJ_MGR_E_VERSION_MISMATCH. То что описано выше - реализация оптимистичной блокировки, не более и не менее. К транзакициям это имеет ровно только одно отношение: контент-сервер инвалидирует транзакцию в случае возниковения ошибки:



checkout() - метод, предназначенный для закрепления права редактирования документа (свойств и контента) за определенным пользователем, вся магия, которая в нем делается - выставление атрибутов r_lock_owner, r_lock_date и r_lock_machine (последний полезен разве что в случае нескольких серверов, обслуживающих один репозиторий), дальше идет исключительно конвенция - если атрибут r_lock_owner не пустой и не равен имени текущего пользователя, то текущий пользователь не может вносить изменения в объект. Ввиду того, что это просто конвенция, то реализовать какие-либо блокировки на ней нельзя. Справедливости ради нужно сказать, что индусы-разработчики также полагают, что checkout() реализует блокировку, хотя это не так, пример как две сессии успешно "блокируют" объект одновременно:


checkin() - метод, определяющий ветвление версий, save() - сохранение объекта в СУБД со снятием флага r_lock_owner, если таковой взведен, saveLock() - сохранение объекта в СУБД без снятия флага r_lock_owner. Вообщем тут опять не про транзакции.


До DFC6, действительно, транзакцию можно было начать только в менеджере сессий, но при именно при этом вызове транзакция начитается в жавском коде, транзакции, начатые через менеджер сессий реализуют только часть XA - сам лично заводил дефекты, когда в одной сессии изменения сохраняются в СУБД, а во второй - облом. Начиная с DFC6 транзакции можно начинать на уровне сессии, при этом все последующие RPC будут идти в транзакции. Но тут есть один довольно плохой момент - транзакции также вяжутся к жавскому-потоку, поэтому выполять траезакционный код можно только в одном потоке.

lock() - жавский метод, заставляющий контент-сервер выпонять такой запрос:

Т.е. по сути в СУБД на строку накладывается row-level lock, больше никакой магии тут нет. Поскольку row-level lock можно снять только либо закоммитив либо прервав транзакцию, то метод lock() должен выполняться в транзакции (чисто формально такое ограничение накладывает только DFC, а не контент-сервер, поэтому можно извернуться явно транзакцию не начинать, то смысла это не несет). lockEx() от lock() отличается только тем, что позволяет узнать модифицировался ли объект пока вызвов lockEx() пытался заблокировать строку или нет, что само по себе смысла никакого не имеет, потому что типичый паттерн исподьзования lock() выглядит так:




PS. довольо опрометчиво называть человека, который знает документум вдоль и поперек, написал собственные реализации протокола на perl и python, лохом - можно и говна нажраться



Partisan MЕсли отбросить словесный мусор, то правда в этом тексте состояла в том, что кроме Java API существует JavaScript API. Пользоваться им необязательно, но ничего плохого нет в том, что предоставлена такая возможность. Конечно, можете еще рассказать как там полностью отсуствует поиск по значениям атрибутов - можно использовать только полнотекстовый lucene, также расскажите как альфреска начинает замечательно глючить, если вдруг полнотекстовый индекс похерился.

iscrafmЗаказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.Главное чтобы заказчик понимал что он действительно хочет, а тут зачастую бывает что ФЗ - делопроизводы, требования пишут IT, а на выходе крокодил. Делать маленькие проекты на документуме смысла нет - они будут задействовать от силы процетов 10 функциональности платформы, а бабки за лицензии будут платиться за то, что успели написать индусы за много лет. Сейчас обещают сделать бесплатный (соответствено неподдерживаемый) порт на postgresql, если сделают на основе прямого билда, то по лицензиям можно довольно сильно упасть будет.

iscrafmа что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильногоВ целом - все, под спойлером написано почему.

iscrafmпод спойлером программерские рассуждения на туже тему. Вы наверное не совсем поняли о чем оппонент говорил и тоже самое с кучей кода зачем-то привелиВ каком месте вы считаете, что то же самое?
авторсамая слабая (блокирвка) - метод fetch () в классе IDfPersistentObject бред, пояснил по какой причине.
авторзатем выпискабред, пояснил по какой причине. и т.д.

iscrafmя заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не болееТам топик исключительно про то, что почему пограмисты пишут хрень. Если вы пожете разумно пояснить почему fetch() (чтение актуального состояние объекта из СУБД) внезапно стал блокировкой, то я с Вами, пожалуй, соглашусь

iscrafmделать маленькие проекты на нем смысла нет по другой причине, выше озвучил: тоже самое можно сделать другими средствами проще и разумней. Возможности Documеntum здесь не причем. Как у любого монстрообразного продукта, разрабатываемого разными коллективами и в разные годы - родовая травма: сборная солянка. Поэтому ввязываться можно только если проект огромный, по причине отсутствия проверенных предложенийВы не могли бы развернуть свою мысль более подробно? Вот берем ядро: Content Server + DFC, это 474 вызова RPC в контент-сервере, некоторый набор базовых сущностей (пользователь, группа, папка, документ и пр.) + некий шлак в виде небазовых сущностей, которые впихнул вендор, чтобы можно было продать продукт без кастомизации + стек DFC, реализующий все RPC на клиенте и поддерживающий базовые правила работы с баовыми сущностями. Здесь вроде как солянки нет, за исключением того, что отмечено как "шлак" (который вроде как и не заметен особо), вместо солянки присуствует куча legacy-функционала (например те же жизненные циклы), который убрать нельзя, потому что текущие заказчики дадут п.ды. Дальше BPM: 6 (могу ошибаться) вариантов выбора исполнителей активностей, 2 вида активностей (ручные/автоматические), пара десятков предустановленных шаблонов активностей - в целом ничего лишнего нет, наблюдается скорее отсуствие функционала (ну например встроенных decision rules ой как не хватат). Webtop - здесь да, проблема: в коде нет вообще никакой конвенции, разные компоненты реализованы по-разному (в плане конвенции), что творится в кастомизациях партнеров вообще уму непостижимо. xCP/xCP2/D2 - точно без солянки, но у них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься. DFS/CMIS/REST - ну это просто сервисы, реализующие некоторую часть DFC, то что сверху - ответственность исполнителя.

iscrafmт.е. вы понятие "блокировка" не воспринимаете дальше, чем его интерпретирует СУБД. То, что, например, пользователь закрепил за собой право распоряжаться каким-то объектом другим способом "блокировкой" уже по вашему не является.Почему же не воспринимаю? Оно для пользователя выглядит так: если никто не выписал, то значка нет, если выписал текущий пользователь, то ключик, если не текущий - замочек. Т.е. в зависимости от того, какое значение атрибута, пользователь видит ту или иную иконку, и лишний раз никуда не лезет, т.е. для бизнес-пользователя оно работает ожидаемо, но
авторэто блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных) бред.

iscrafmт.е. разница только в том, что ваш оппонент назвал гарантированное чтение объекта с обеспечение его логической целостности на данный момент времени "блокировкой", в терминах. По большому счету это можно назвать кратковременной блокировкой на момент чтения, гарантированно получить целостный объектВообще совершенно разные понятия. Вы приходите в магазин смотрите сколько стоит арбуз и сколько примерно есть - это fetch, никакой блокировкой тут не пахнет, дальше подходите к продавцу и просите принести 10 арбузов (вы прикинули что десяток точно наберется), продавец ушел за арбузом - Вы пессимистичо заблокировали продавца (его никто больше использовать не может), пока продавец ходил арбузы разобали и осталось 9, он приходит и говорит: "Осталось 9" - это оптимистичная блокировка, Вы в праве решить брать 9 или уйти, что там Вы видели в начале своей бизнес-транзакции никого не волнует - нужно было резервировать нужное количество в самом начале (пессимистичная блокировка)

iscrafmАндрей Панфилову них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься .
это и имеется ввиду.Дык у этих продуктов целевая аудитория как раз мелкие заказчики (с оговоркой на то, что продаванам нужно продавать и они впаривают все подряд без разбора, а заказчик не поимает к чему это приведет).

iscrafmхорошо. давайте на бытовых примерах.
...У Вас пример несколько натянут для того, чтобы попытаться приплести RC к блокировке, ну нет там блокировки и все. Кроме этого гаратий тоже нет никаких: пока продавец выходил в подсобку халат украли, клиент данные вроде как получил, которые были консистентны мгновение назад, но смысла в них нет никакого. В документуме работает по-умолчанию оптимистичная блокировка, но реализуется она двумя вызовами: fetch() (который с клову сказать бывает неявным и бывает холостым) и save().

iscrafm,

ну ответ пришел консистентный, только где блокировка-то? в базе ее нет, с т.з. пользователя ее тоже нет.

Garya,

Я хотел бы обратить Ваше внимание на то, что обсуждается вполне определеный продукт, работающий со вполне определенными СУБД с вполне определенными (вендором) настройками. Для ORACLE UR вообще нет, для MSSQL рекомедуется READ_COMMITTED_SNAPSHOT=ON, поэтому все гипотетические предположения о том, что продукт (т.е. documentum) при реализации определенных RPC накладывает блокировки в СУБД, остаются гипотетическими. Можно скольку угодно пытаться найти хоть какую-то истину в изначально неверном утверждении, но ни к чему толковому это не приведет.