powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Состааввление требований к исключению Documentum и OpenText
25 сообщений из 77, страница 2 из 4
Состааввление требований к исключению Documentum и OpenText
    #38530520
Partisan M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ПанфиловНе особо вяжется с этой мурзилкой:

Вы чего хотели выразить? Впрочем, неважно. Вяжется.
Но приходится ещё раз предупредить, что Documentum - не для лохов, значит и не для вас, если только вы не относитесь к интеграторам, которые впаривают лохам фуфло. Тогда для вас. Хотя тоже вряд ли, потому что следующая цитата из вас - полная чушь, показывающая незнакомство с темой:

Андрей ПанфиловВ итоге то что действительно похороили - xCP, но лично мне изначально казалось что он не жилец особо, к нам как-то приходил сейл из EMC и пытался впарить коробку EPFM, проблема в том, что EPFM начали делать через год-два после появления xCP, вот только проблема в том, что сделано оно на webtop, что говорит само за себя о возможностях xCP.

МихаилРОтдельное спасибо за ремару по поводу Alfresco.

Про Alfresco лучше узнайте у тех, кто сам знает.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530528
Partisan M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов(мы для внутренних целей используем альфреску, причем в наличии есть грамотные разработчики, впечатление такое, что коробочный webtop куда функциональнее и удобнее чем альфреска, кроме этого по отзывам разработчиков складывается впечатление, что альфреска представляет из себя некий фарш из жавы и сервеного жаваскрипта, кроме этого база используется как EAV, так что с отчетами и поиском ой какая беда)

Это я процитировал для подтверждения своего высказывания, что об Alfresco надо узнавать у тех, кто знает, а здесь таких нет.
Если отбросить словесный мусор, то правда в этом тексте состояла в том, что кроме Java API существует JavaScript API. Пользоваться им необязательно, но ничего плохого нет в том, что предоставлена такая возможность.
Тут ещё было мнение, что автоматические активности пишутся на JavaScript. Тоже нобязательно - есть разные виды: можно на Java, можно на скриптовом языке (часто используются JavaScript и Groovy, но можно и другие на платформе Java).
В общем. Я изучаю Alfresco по документации, что и другим советую, а с вопросами можно обращаться к интеграторам.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530545
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловкрупных заказчиков не осталось, а мелким Documentum не нужен.
Заказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530567
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Partisan MВяжется.конечно, Ваше утверждение "я знаю документум" и 10985752 корелируют с коэффициентом -1.


Partisan MТранзакции в Документуме есть, и длинные и короткие (только они так не называются). Длинные реализуются как жизненные циклы (lifecycle). Жизненный цикл это последовательность состояний объекта, состояние - согласованный набор атрибутов (параметров). Контроль согласованности осуществляется: как без программирования (заданием условий вхождения в состояние), так и с ним (отдельной процедурой жизненного цикла, написанной на Java или языке DocBasic).
Что-то не увидел в каком месте состояние ЖЦ является согласованым набором атрибутов. Состояния ЖЦ в документуме это всего-лишь способ сделать некоторые изменения в СУБД/контенте/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() передает запомненное значение обратно контет-серверу, тот в свою очередь сохраняет изменения в СУБД примерно таким вот запросом:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
UPDATE DM_SYSOBJECT_S dm_dbalias_B  
   SET R_MODIFY_DATE =  
          TO_DATE ('2013/12/28.11.30.38', 'YYYY/MM/DD.HH24.MI.SS'),  
       R_MODIFIER = 'dmadmin',  
............................  
       I_VSTAMP = 4  
WHERE (    dm_dbalias_B.R_OBJECT_ID = '0801d920805278c4'  
        AND dm_dbalias_B.I_VSTAMP = 3) 



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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
    API> fetch,s0,0801ffd780051c27  
    ...  
    OK  
    API> begintran,s1  
    ...  
    OK  
    API> fetch,s1,0801ffd780051c27  
    ...  
    OK  
    API> save,s0,l  
    ...  
    OK  
    API> save,s1,l  
    ...  
    [DM_SYSOBJECT_E_CANT_SAVE]error:  "Cannot save 0801ffd780051c27 sysobject."  
    [DM_SYSOBJECT_E_VERSION_MISMATCH]error:  "save of object failed because of version mismatch:  
      old version was 0"  
      
    API> fetch,s1,l  
    ...  
    OK  
    API> save,s1,l  
    ...  
    [DM_SESSION_E_TRANSACTION_ERROR]error:  "Transaction invalid due to errors,  
      please abort transaction."  


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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
API> fetch,s0,0901ffd780051c49  
...  
OK  
API> fetch,s1,0901ffd780051c49  
...  
OK  
API> checkout,s0,l  
...  
0901ffd780051c49  
API> checkout,s1,l  
...  
0901ffd780051c49 

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


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

lock() - жавский метод, заставляющий контент-сервер выпонять такой запрос:
Код: sql
1.
2.
3.
UPDATE dm_sysobject_s  
   SET i_vstamp = i_vstamp  
WHERE r_object_id = '0801d92080528ce6' 

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

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
public static boolean startTransactionIfNotActive(IDfSession session)  
    throws DfException {  
    boolean transactionActive = session.isTransactionActive();  
    if (!transactionActive) {  
        session.beginTrans();  
    }  
    return !transactionActive;  
}  
  
boolean txStartsHere = false;  
try {  
    txStartsHere = startTransactionIfNotActive(session);  
    object.lock();  
    object.fetch(null);  
    // perform modifications  
    object.save();  
    if (txStartsHere) {  
        session.commitTrans();  
    }  
} finally {  
    if (txStartsHere && session.isTransactionActive()) {  
        session.abortTrans();  
    }  
} 



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



Partisan MЕсли отбросить словесный мусор, то правда в этом тексте состояла в том, что кроме Java API существует JavaScript API. Пользоваться им необязательно, но ничего плохого нет в том, что предоставлена такая возможность. Конечно, можете еще рассказать как там полностью отсуствует поиск по значениям атрибутов - можно использовать только полнотекстовый lucene, также расскажите как альфреска начинает замечательно глючить, если вдруг полнотекстовый индекс похерился.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530571
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ПанфиловPartisan MВяжется.конечно, Ваше утверждение "я знаю документум" и 10985752 корелируют с коэффициентом -1.
а что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильного
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530578
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmЗаказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.Главное чтобы заказчик понимал что он действительно хочет, а тут зачастую бывает что ФЗ - делопроизводы, требования пишут IT, а на выходе крокодил. Делать маленькие проекты на документуме смысла нет - они будут задействовать от силы процетов 10 функциональности платформы, а бабки за лицензии будут платиться за то, что успели написать индусы за много лет. Сейчас обещают сделать бесплатный (соответствено неподдерживаемый) порт на postgresql, если сделают на основе прямого билда, то по лицензиям можно довольно сильно упасть будет.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530579
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmа что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильногоВ целом - все, под спойлером написано почему.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530584
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ПанфиловiscrafmЗаказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.Главное чтобы заказчик понимал что он действительно хочет, а тут зачастую бывает что ФЗ - делопроизводы, требования пишут IT, а на выходе крокодил. Делать маленькие проекты на документуме смысла нет - они будут задействовать от силы процетов 10 функциональности платформы, а бабки за лицензии будут платиться за то, что успели написать индусы за много лет. Сейчас обещают сделать бесплатный (соответствено неподдерживаемый) порт на postgresql, если сделают на основе прямого билда, то по лицензиям можно довольно сильно упасть будет.
делать маленькие проекты на нем смысла нет по другой причине, выше озвучил: тоже самое можно сделать другими средствами проще и разумней. Возможности Documеntum здесь не причем. Как у любого монстрообразного продукта, разрабатываемого разными коллективами и в разные годы - родовая травма: сборная солянка. Поэтому ввязываться можно только если проект огромный, по причине отсутствия проверенных предложений
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530585
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловiscrafmа что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильногоВ целом - все, под спойлером написано почему.
под спойлером программерские рассуждения на туже тему. Вы наверное не совсем поняли о чем оппонент говорил и тоже самое с кучей кода зачем-то привели
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530595
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmпод спойлером программерские рассуждения на туже тему. Вы наверное не совсем поняли о чем оппонент говорил и тоже самое с кучей кода зачем-то привелиВ каком месте вы считаете, что то же самое?
авторсамая слабая (блокирвка) - метод fetch () в классе IDfPersistentObject бред, пояснил по какой причине.
авторзатем выпискабред, пояснил по какой причине. и т.д.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530603
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловавторсамая слабая (блокирвка) - метод fetch () в классе IDfPersistentObject бред, пояснил по какой причине.
я заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не более
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530607
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmя заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не болееТам топик исключительно про то, что почему пограмисты пишут хрень. Если вы пожете разумно пояснить почему fetch() (чтение актуального состояние объекта из СУБД) внезапно стал блокировкой, то я с Вами, пожалуй, соглашусь
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530608
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmАндрей Панфиловпропущено...
бред, пояснил по какой причине.
я заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не более
т.е. вы понятие "блокировка" не воспринимаете дальше, чем его интерпретирует СУБД. То, что, например, пользователь закрепил за собой право распоряжаться каким-то объектом другим способом "блокировкой" уже по вашему не является.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530613
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmделать маленькие проекты на нем смысла нет по другой причине, выше озвучил: тоже самое можно сделать другими средствами проще и разумней. Возможности Documеntum здесь не причем. Как у любого монстрообразного продукта, разрабатываемого разными коллективами и в разные годы - родовая травма: сборная солянка. Поэтому ввязываться можно только если проект огромный, по причине отсутствия проверенных предложенийВы не могли бы развернуть свою мысль более подробно? Вот берем ядро: Content Server + DFC, это 474 вызова RPC в контент-сервере, некоторый набор базовых сущностей (пользователь, группа, папка, документ и пр.) + некий шлак в виде небазовых сущностей, которые впихнул вендор, чтобы можно было продать продукт без кастомизации + стек DFC, реализующий все RPC на клиенте и поддерживающий базовые правила работы с баовыми сущностями. Здесь вроде как солянки нет, за исключением того, что отмечено как "шлак" (который вроде как и не заметен особо), вместо солянки присуствует куча legacy-функционала (например те же жизненные циклы), который убрать нельзя, потому что текущие заказчики дадут п.ды. Дальше BPM: 6 (могу ошибаться) вариантов выбора исполнителей активностей, 2 вида активностей (ручные/автоматические), пара десятков предустановленных шаблонов активностей - в целом ничего лишнего нет, наблюдается скорее отсуствие функционала (ну например встроенных decision rules ой как не хватат). Webtop - здесь да, проблема: в коде нет вообще никакой конвенции, разные компоненты реализованы по-разному (в плане конвенции), что творится в кастомизациях партнеров вообще уму непостижимо. xCP/xCP2/D2 - точно без солянки, но у них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься. DFS/CMIS/REST - ну это просто сервисы, реализующие некоторую часть DFC, то что сверху - ответственность исполнителя.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530614
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
т.е. разница только в том, что ваш оппонент назвал гарантированное чтение объекта с обеспечение его логической целостности на данный момент времени "блокировкой", в терминах. По большому счету это можно назвать кратковременной блокировкой на момент чтения, гарантированно получить целостный объект
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530617
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилову них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься .
это и имеется ввиду.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530619
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmт.е. вы понятие "блокировка" не воспринимаете дальше, чем его интерпретирует СУБД. То, что, например, пользователь закрепил за собой право распоряжаться каким-то объектом другим способом "блокировкой" уже по вашему не является.Почему же не воспринимаю? Оно для пользователя выглядит так: если никто не выписал, то значка нет, если выписал текущий пользователь, то ключик, если не текущий - замочек. Т.е. в зависимости от того, какое значение атрибута, пользователь видит ту или иную иконку, и лишний раз никуда не лезет, т.е. для бизнес-пользователя оно работает ожидаемо, но
авторэто блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных) бред.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530626
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmт.е. разница только в том, что ваш оппонент назвал гарантированное чтение объекта с обеспечение его логической целостности на данный момент времени "блокировкой", в терминах. По большому счету это можно назвать кратковременной блокировкой на момент чтения, гарантированно получить целостный объектВообще совершенно разные понятия. Вы приходите в магазин смотрите сколько стоит арбуз и сколько примерно есть - это fetch, никакой блокировкой тут не пахнет, дальше подходите к продавцу и просите принести 10 арбузов (вы прикинули что десяток точно наберется), продавец ушел за арбузом - Вы пессимистичо заблокировали продавца (его никто больше использовать не может), пока продавец ходил арбузы разобали и осталось 9, он приходит и говорит: "Осталось 9" - это оптимистичная блокировка, Вы в праве решить брать 9 или уйти, что там Вы видели в начале своей бизнес-транзакции никого не волнует - нужно было резервировать нужное количество в самом начале (пессимистичная блокировка)
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530628
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmАндрей Панфилову них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься .
это и имеется ввиду.Дык у этих продуктов целевая аудитория как раз мелкие заказчики (с оговоркой на то, что продаванам нужно продавать и они впаривают все подряд без разбора, а заказчик не поимает к чему это приведет).
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530639
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хорошо. давайте на бытовых примерах.
покупатель желает белый халат в красной коробке. Белый халат в красной коробке - это объект. Вопрос покупателя продавцу о таком объекте - это вызов fetch. Ответ продавца - это возрат fetch. Так вот пока продавец идет из подсобки с ответом - действует блокировка белого халата в красной коробке, чтобы когда продавец дойдет до покупателя с ответом не случилось конфуза: пока он шел забрали или белый халат или красную коробку для того, чтобы положить в нее зеленый халат. Это просто чтение с гарантированно целостным ответом. Блокировка действует мгновение, пока продавец не ответит. Потом, пока покупатель будет думать брать или не брать конечно ничего в данном варианте не блокируется. Обычное гарантированное чтение READ COMMITED, если в термины СУБД перевести
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530644
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmхорошо. давайте на бытовых примерах.
...У Вас пример несколько натянут для того, чтобы попытаться приплести RC к блокировке, ну нет там блокировки и все. Кроме этого гаратий тоже нет никаких: пока продавец выходил в подсобку халат украли, клиент данные вроде как получил, которые были консистентны мгновение назад, но смысла в них нет никакого. В документуме работает по-умолчанию оптимистичная блокировка, но реализуется она двумя вызовами: fetch() (который с клову сказать бывает неявным и бывает холостым) и save().
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530657
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловпока продавец выходил в подсобку халат украли, клиент данные вроде как получил, которые были консистентны мгновение назад, но смысла в них нет никакого.
есть ли в них смысл или нет - другой вопрос. Здесь важно то, что на время ответа (это самое мгновение назад) должна быть гарантия правильности ответа. Иначе обычное "грязное" чтение.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38530659
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafm,

ну ответ пришел консистентный, только где блокировка-то? в базе ее нет, с т.з. пользователя ее тоже нет.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38531093
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловбред.

Модератор: Уважаемый Андрей Панфилов, очень Вас прошу избегать подобных "интегральных оценок" высказываниям иных участников обсуждения. Это накаляет атмосферу и, откровенно говоря, не красит Вас лично, демонстрируя Ваши амбиции. Высказывайте, пожалуйста, аргументы, а не выставляйте оценки. Тем более, как показывает обсуждение с iscrafm, Вы и сами не до конца понимаете, о чем идет речь. При неоднократном чтении атрибутов одного и того же объекта можно именно на операциях чтения "заявить", допускается, либо не допускается изменение атрибутов объекта за пределами транзакции, только в зафиксированных транзакциях или в незафиксированных тоже и, соответственно, при повторных чтениях внутри текущей транзакции будут допускаться или не будут допускаться изменения атрибутов объекта внешними зафиксированными транзакциями, либо незафиксированными транзакциями ("грязное чтение"). И это тоже разновидность блокировки, а вовсе не "бред". Заносчивость иногда играет злую шутку с теми, кем она овладела.
...
Рейтинг: 0 / 0
Состааввление требований к исключению Documentum и OpenText
    #38531129
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Garya,

Я хотел бы обратить Ваше внимание на то, что обсуждается вполне определеный продукт, работающий со вполне определенными СУБД с вполне определенными (вендором) настройками. Для ORACLE UR вообще нет, для MSSQL рекомедуется READ_COMMITTED_SNAPSHOT=ON, поэтому все гипотетические предположения о том, что продукт (т.е. documentum) при реализации определенных RPC накладывает блокировки в СУБД, остаются гипотетическими. Можно скольку угодно пытаться найти хоть какую-то истину в изначально неверном утверждении, но ни к чему толковому это не приведет.
...
Рейтинг: 0 / 0
25 сообщений из 77, страница 2 из 4
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Состааввление требований к исключению Documentum и OpenText
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]