Axapta 3.0 Kernel Rollup 1 Service Pack Release

[Vadik]

Цитата:

Сообщение от Maxim Gorbunov

И про Optimistic Concurrency Checking кто-нибудь может доходчиво объяснить, что имелось ввиду? Опять же, в моем переводе:
1. Раньше перед выполнением update, Axapta перечитывала запись с сервера, сравнивала ее с той, что хранилась в памяти и, если они были одинаковыми, строила новую запись и записывала ее в БД.
2. Теперь Axapta также перечитывает запись c сервера и, если она не изменилась, выполняет update.
3. Короче говоря, если нет конфликта, то выполняется только один запрос к БД.

Вызывает интерес значение именно пункта 3: почему один-то, когда запись все равно перечитывается?

Дело в следующем (с). Как уже писалось на axforum-е, сейчас в структуре данных добавлено новое поле - RECVERSION, инициализируется оно значением 1, далее при каждой модификации оно меняется (как генерируется - непонятно, да и не важно, допустим, случайным образом, главное, что две сессии сгенерят два разных значения). При изменении (UPDATE) записи

РАНЬШЕ:
- запись перечитывалась по RecId (select * from myTable where DataAreaId = .. and RecId = ..
- изменения, которые могли быть сделаны другими сессиями, merge-ились с изменениями в текущей сессии

СЕЙЧАС:
- запись не перечитывается, сразу выполняется update myTable where DataAreaId = .. and RecId = .. and RECVERSION = ..
если кто-то уже изменил эту запись, поле RECVERSION имеет уже другое значение и фактически мы "пролетаем" с оператором UPDATE - количество обработанных записей (@@ROWCOUNT) = 0. Поэтому система перечитает запись по RecId и продолжит работу как ни в чем ни бывало (по старому алгоритму)

Т.е. количество операций в среднем по системе таки должно уменьшаться и выигрыш вроде бы есть. Единственное НО: этот механизм работает только на формах (данные, которые отбираются для изменения из кода, уже заблокированы с select forupdate), а данные на формах (по моим ощущениям) вроде бы не особо интенсивно меняются. Стоило ли для это добавлять новое поле во все таблицы - ну, вендору виднее