![]() |
#9 |
Модератор
|
Цитата:
Сообщение от Maxim Gorbunov
![]() И про Optimistic Concurrency Checking кто-нибудь может доходчиво объяснить, что имелось ввиду? Опять же, в моем переводе:
1. Раньше перед выполнением update, Axapta перечитывала запись с сервера, сравнивала ее с той, что хранилась в памяти и, если они были одинаковыми, строила новую запись и записывала ее в БД. 2. Теперь Axapta также перечитывает запись c сервера и, если она не изменилась, выполняет update. 3. Короче говоря, если нет конфликта, то выполняется только один запрос к БД. Вызывает интерес значение именно пункта 3: почему один-то, когда запись все равно перечитывается? РАНЬШЕ: - запись перечитывалась по RecId (select * from myTable where DataAreaId = .. and RecId = .. - изменения, которые могли быть сделаны другими сессиями, merge-ились с изменениями в текущей сессии СЕЙЧАС: - запись не перечитывается, сразу выполняется update myTable where DataAreaId = .. and RecId = .. and RECVERSION = .. если кто-то уже изменил эту запись, поле RECVERSION имеет уже другое значение и фактически мы "пролетаем" с оператором UPDATE - количество обработанных записей (@@ROWCOUNT) = 0. Поэтому система перечитает запись по RecId и продолжит работу как ни в чем ни бывало (по старому алгоритму) Т.е. количество операций в среднем по системе таки должно уменьшаться и выигрыш вроде бы есть. Единственное НО: этот механизм работает только на формах (данные, которые отбираются для изменения из кода, уже заблокированы с select forupdate), а данные на формах (по моим ощущениям) вроде бы не особо интенсивно меняются. Стоило ли для это добавлять новое поле во все таблицы - ну, вендору виднее
__________________
-ТСЯ или -ТЬСЯ ? |
|