Garya,

Ничего особеного не происходит, у каждой своя собственная копия объекта, эти копии между сессиями никак не синхронизируются, копия представляет из себя некоторое состояние объекта полученное из СУБД + изменения произведенные клиентским кодом, эти локальные изменения можно "откатить" до актуального состояния объекта, также можно сравнить текущий объект с актуальным состоянием. GaryaЧто значит "нет блокировок"?на двух самых популярных поддерживаемыз СУБД (насчет DB2 не знаю ничего) читатели не блокируют писателей, и наоборот. Факт того, что сохранение объекта происходит в актуальную версию устанавливается только при сохранении объекта в СУБД - при апдейте выясняется актуальность пары (id_объекта, счетчик_сохранений), сохранение объекта в одной сессии не инвалидируют копии этого объекта в других сессиях, т.е. шаблон сохранения изменений такой:

1. получить актуальную копию (fetch из JVM)
2. внести изменения (меняется копия объекта в JVM)
3. попытаться сохранить (сохраение измеений в СУБД)
4. если сохранить не удалось из-за неактуального состояния, то 1

iscrafmтогда не актуальную версию, а snapshot на момент чтенияКак Вам будет угодно, главное не называть блокировкой. Хотя технически нельзя сказать, что fetch - получение снапшота объекта из базы: после того как сессия один раз читает объект он сохраняется в ее кеше, в следствие чего последующие вызовы fetch() в большинстве случаев получаются холостыми: он сначала проверяет, насколько пара (id_объекта, счетчик_сохранений) актуальна и только в случае неактуальности делает чтение из базы (тут может возникнуть ситуация, когда кто-то сделал изменения в СУБД при помощи SQL и эти изменения в JVM не засосутся), получается, что если объект модифицировался в JVM, то fetch либо ничего не делает с объектом, либо затирает все изменения в зависимости от текущего значения счетчика сохранений. В действительности для уже существующего в JVM синхронизация с СУБД выполняется только при вызовах revert() и save().

iscrafm,

вроде уже писал: 15437081

iscrafm,

Есть мнение, что отходить от рекомендаций вендора плохо. Давайте чтоли проясним ситуацию с утверждением:

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

к транзакциям он тоже особого отношения не имеет

строго говоря, любой объект одновременно менять могут в куче сессий, весь вопрос как как они его будут сохранять

все блокировки, которые можно сделать в документуме осуществляются только на уровне СУБД, а не некие "самые строгие"

iscrafm,

не вижу. Выделенное неверно

автор Есть нескольуо уровней блокировки, на самом строгом она осуществляется и на уровне базы данных. Эти уровни:
- самая слабая - метод fetch () в классе IDfPersistentObject. Не обеспечивает закрепления объекта за одним пользователем (другие могут менять), а только получение последней версии .

iscrafm,

Вы тут зря аппелируете к документации - EMC совершенно безобразно относится к документации по продукту, они ее никогда не актуализируют, базу знаний ведут безобразно, даже список измеений в патчах не могут предоставить: постоянно возикают ситуации когда пишут что исправление включено в патч, а на самом деле его нет, либо включают какую-то непонятную фигню, а в release notes не упоминают.

Касательно Вашего жавадока, т.е.:

автор /**
* Fetches this object from the repository without placing a lock on the object.
* <p/>
* Use this method to ensure that you are working with the most recent version of the object. You must
* have at least BROWSE permission on an object to call the <CODE>fetch</CODE> method.
* <p/>
* Without a lock, there is no guarantee that you will be able to save any changes you make to the object
* since another user may checkout the object while you have it fetched. If you fetch an object, you
* cannot use the <code>checkin</code> method to write the object back to the repository. You must use the
* <code>save</code> method.
*
* @param typeNameIgnored The type name argument is ignored because the type name was set or determined at
* creation of the DfPersistentObject and is therefore already known. Overriding
* the value here would just cause an error. The parameter still exists for
* backward compatability, but should be specified as null.
*
* @throws DfException if a server error occurs
* @see #revert
* @see #fetchWithCaching
*/
public boolean fetch (String typeNameIgnored) throws DfException;


/**
* Discards any changes to an object that have not been saved to a repository.
*
* @throws DfException if a server error occurs
*/
public void revert () throws DfException;



давайте посмотрим как на самом деле все происходит. Во-первых мне совершенно не ясна фраза "Use this method to ensure that you are working with the most recent version of the object", поскольку метод работает следующим образом:

1. для только что созданных объектов он всегда возвращает false, вроде как это правильно если связать поведение с тем фактом, что объекта в базе нет, но формально в таком случае копия объекта в JVM всегда актуальная (при этом isCurrentWithServer() для овых объектов возвращает true)
2. далее этот метод шлет rpc IsCurrent чтобы понять поменялся у объекта счетчик сохранений или нет, если не поменялся возвращает false, если поменялся, то меняет состояние объекта в JVM (при этом затирает локальные изменения) и возвращает true.

т.е. на самом деле получается что возвращаемое значение - это информация о том, была ли произведена синхронизация объекта с СУБД или нет, но в таком случае толку от этого значения никакого - получается игра в рулетку: состояние может помеяться в результате вызова, а может и не поменяться, при таком раскладе правльнее использовать revert() вместо fetch().

Далее. revert() - "Discards any changes to an object that have not been saved to a repository.", вот опять описание неверное, он локальные измеения откатывает и при этом замещает данные в JVM актуальными данными из СУБД, а не просто откатывает локальные изменения.

iscrafmимхо, спор ни о чем
я уже Вам раз пять написал, что претензия к тому, что метод отнесен к каким-то нясным уровням блокировок.

А вообще, использование fetch() в коде - дурной тон: DFC при вызовах getObject()/getObjectByQualification() пытается вытащить объект из кеша и само актуализирует его состояние в случае если isDirtry() (маркер модификации объекта в JVM) возвращает false, но если в кеше лежат грязные объекты, то это означает одно из:
кто-то поменял состояние, но не вызвал save()

при ошибке вызова save() кто-то не сделал revert()

363,

какая жесть написана-то...

авторссылаясь на ограничения устаревшей платформысерверная часть 5.3 практически (в плане производительности уж точно ничем) ничем не отличается от "современной" 7.1. Здесь за апгрейд играют два фактора:
5.3 - java 1.4, никто связываться с этим уже не хочет

поддержка, если не ошибаюсь, закончилась в 2008, т.е. с одной стороны часть проблем на вендора уже не слить, а вот вендор за апгрейд получит денюжку (офоициально нужно проплатить пропущенные периоды поддержки, неофициально - как договорятся)

авторпересоздать СЭД (поскольку старая и новая версия платформы несовместимы)В новых версиях webtop отломали только поиск, остальное практически не поменялось. Здесь "новая версия платформы несовместимы" либо попахивает бредом, либо предложили перевести все на бета-версию xcp.

автор что выполнение некоторых элементарных операций (например, открытие карточки документа) в ряде случаев при большом числе одновременно работающих пользователей занимает до минуты и даже более времениЕсли модель данных кривая, то тут никакие апгрейды не помогут.