AXForum  
Вернуться   AXForum > Прочие обсуждения > Детская
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.10.2019, 13:33   #21  
trud is offline
trud
Участник
Лучший по профессии 2017
 
792 / 1031 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от NitroJunkie Посмотреть сообщение
Но в READ COMMITED блокировка же не держится в рамках всей транзакции. Или предполагается что обновление остатков всегда идет ровно одним запросом? И сквозного использования данных в рамках одной транзакции предполагается нет?
В READ COMMITED SNAPSHOT блокировок вообще нет. т.е. в общем случае предполагается что если у вас 2 сессии меняют одно и тоже, то у вас что-то не в порядке с бизнес процессами и одна из сессий при попытке сохранения записи получит сообщение о ошибке - "Запись изменена другим пользователем, обновите форму".
Есть еще много частных случаев - например в случае остатков, они не меняются при обработке документа, вместо этого создается лог изменений и по событию окончания транзакции этот лог записывается в основную таблицу.
Вот еще несколько частных случаев - https://denistrunin.com/understanding-sql-blocking

Последний раз редактировалось trud; 07.10.2019 в 13:36.
Старый 07.10.2019, 14:29   #22  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Цитата:
Сообщение от trud Посмотреть сообщение
В READ COMMITED SNAPSHOT блокировок вообще нет. т.е. в общем случае предполагается что если у вас 2 сессии меняют одно и тоже, то у вас что-то не в порядке с бизнес процессами и одна из сессий при попытке сохранения записи получит сообщение о ошибке - "Запись изменена другим пользователем, обновите форму".
Есть еще много частных случаев - например в случае остатков, они не меняются при обработке документа, вместо этого создается лог изменений и по событию окончания транзакции этот лог записывается в основную таблицу.
Вот еще несколько частных случаев - https://denistrunin.com/understanding-sql-blocking
Я знаю, что такое READ COMMITED SNAPSHOT. Речь о том, что если например сделать сначала select во временную таблицу (или написать while select), а только потом update, то если уровень изоляции не RR (ставится блокировка или проверяется update conflict), может получится некорректный показатель из-за non-repeatable read.
Старый 07.10.2019, 14:36   #23  
trud is offline
trud
Участник
Лучший по профессии 2017
 
792 / 1031 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Не понял фразы "некорректный показатель". Возможно надо обсудить пример.
Но вся система на этом построена, проблемы с некорректностью чего-то я даже и не припомню. Repeatable Read будет блокировать сессии, АХ так не работает
Старый 07.10.2019, 18:08   #24  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Цитата:
Сообщение от trud Посмотреть сообщение
Не понял фразы "некорректный показатель". Возможно надо обсудить пример.
Но вся система на этом построена, проблемы с некорректностью чего-то я даже и не припомню. Repeatable Read будет блокировать сессии, АХ так не работает
Смотрите, вы делаете
x = select quantity from balance where productid = 5;
update balance set quantity = x+2 where productid = 5;

Без RR у вас количество может неправильное записаться, если между первой и второй командой влезет транзакция, которая изменит quantity. Называется non-repeatable read.

https://en.wikipedia.org/wiki/Isolat...peatable_reads
Старый 07.10.2019, 18:22   #25  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,237 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Если коротко, то в Аксапте есть
1. пессимистическая модель обновления (используется редко) когда блокировка ставится в момент выборки на select и тогда никто не вклинится в вашем примере а повиснет в блокировке.
2. оптимистическая модель обновления (это основной случай) когда блокировка ставится только в момент обновления. Тогда ваши опасения обоснованы. Но в Аксапте для этого есть защита. в каждой записи есть поле RecVersion которое меняется при каждом обновлении на другое псевдослучайное значение. И аксапта при выполнении обновления проверяет сохранилось ли это значение на момент обновления таким же как было при выборке, если не сохранилось значит кто-то другой уже влез (то чего вы боитесь) и тогда ядро аксапты выбрасывает исключение "конфликт обновления записей" и либо идет обработка этой ситуации программистом X++ либо идет откат транзакции.

Это все работает внутри открытой транзакции в режиме Read committed
Старый 07.10.2019, 18:24   #26  
trud is offline
trud
Участник
Лучший по профессии 2017
 
792 / 1031 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ну с RR вы получите блокировку, это как-бы не очень хорошо.
АХ по дефолту при update balance set quantity = x+2 where productid = 5; вернет вам ошибку, если запись уже кто-то обновил в другой сессии. Для этого в любой таблице добавляется столбец RecVersion, который рандомно заполняется при обновлениях, и если кто-то обновил запись до вас, у нее будет другое значение RecVersion. но это если не касаться остатков
если говорить о остатках, то вместо
update balance set quantity = x+2 where productid = 5;
будет выполнено insert balanceLog(qty=2, productid = 5) и далее на завершении транзакции этот лог перепишется в таблицу балансов
Старый 07.10.2019, 22:59   #27  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,237 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Вот пример джоба по работе с разными типами блокировок
X++:
static void example(Args _args)
{
    #define.RetryNum(5)
    
    void test(
        ConcurrencyModel    _concurrencyModel = ConcurrencyModel::Auto,
        boolean             _readPast = false)
    {
        InventTable     inventTable;
        ;
        
        try
        {
            ttsbegin;
            inventTable.concurrencyModel(_concurrencyModel);
            if (_readPast)
            {
                inventTable.readPast(_readPast);
            }
            select forceliterals inventTable
                where   inventTable.ItemId == "0000001";
            inventTable.NameAlias += "1";
            inventTable.doupdate();
            ttscommit;
        }
        catch (exception::UpdateConflict)
        {
            if (appl.ttsLevel() == 0)
            {
                if (xSession::currentRetryCount() >= #RetryNum)
                {
                    throw Exception::UpdateConflictNotRecovered;
                }
                else
                {
                    retry;
                }
            }
            else
            {
                throw Exception::UpdateConflict;
            }
        }
    }
    ;

    test(ConcurrencyModel::Optimistic);
    test(ConcurrencyModel::Pessimistic);
}
для случая оптимистичной модели будут такие запросы:
X++:
SELECT A.ITEMID, ... A.RECVERSION,A.RECID 
FROM INVENTTABLE A 
WHERE ((DATAAREAID=N'MRC') AND (ITEMID=N'0000001'))
/* блокировки не накладывается */

X++:
UPDATE INVENTTABLE SET NAMEALIAS=?,RECVERSION=?,MODIFIEDDATE=?,MODIFIEDTIME=?,MODIFIEDBY=? 
WHERE (((DATAAREAID=?) AND (RECID=?)) AND (RECVERSION=?))
/* блокировка накладывается, но добавлено условие на RECVERSION - если другая сессия успела влезть и поменять данные то тогда в базе будет другой RecVersion и наш запрос обновить 0 записей. Ядро этой поймет и бросит исключение Exception::UpdateConflict - которое мы на X++ сможем обработать */


для случая пессимистичной модели будут такие запросы:
X++:
SELECT  A.ITEMID, ... A.RECVERSION,A.RECID 
FROM INVENTTABLE A WITH( UPDLOCK)
WHERE ((DATAAREAID=N'MRC') AND (ITEMID=N'0000001'))
/* блокировка накладывается из-за явного указания WITH( UPDLOCK) */

X++:
UPDATE INVENTTABLE SET NAMEALIAS=?,RECVERSION=?,MODIFIEDDATE=?,MODIFIEDTIME=?,MODIFIEDBY=? 
WHERE ((DATAAREAID=?) AND (RECID=?))
/* блокировка уже есть. Обновляем запись, ее все равно никто не трогал из-за блокировки */



Все запросы работают в READ COMMITTED
В случае оптимистической модели вероятность блокировок значительно ниже. Проверено на практике.

Последний раз редактировалось Logger; 07.10.2019 в 23:07.
Старый 07.10.2019, 23:13   #28  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Logger, trud. Я может чего-то не понимаю, но ведь это же повторение логики версионников. Зачем это Axapta делает, если можно просто включить Serializable и СУБД в версионном режиме, и СУБД сама кинет update conflict?
Старый 07.10.2019, 23:22   #29  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,237 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Затрудняюсь ответить.
Нужно спрашивать тех кто проектировал ядро.
Возможно это делалось для SQL 2000, т.е. для тех случаев когда БД не поддерживает какие-то режимы. Но это только мое предположение.
Когда это проектировали, аксапта еще поддерживала Оракл. Возможно это сказалось.
Старый 08.10.2019, 00:26   #30  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,864 / 2374 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Извините, что встреваю в эту дискуссию, но вы ведете подсчет ангелов на острие иглы. Была сегодня попытка устроить продажу потенциальному клиенту в соседнем селе. Это, как обычно просветляет. Вопросы, которые интересовали собственника предприятия:
1) Сколько стоит
2) Сколько людей нужно нанять, чтобы обслуживать систему
3) Что он за это получит

Другими словами: Функциональные возможности и их Стоимость. Вопросы блокировок его не интересовали.
Старый 08.10.2019, 12:03   #31  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,237 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от EVGL Посмотреть сообщение
Вопросы, которые интересовали собственника предприятия:
1) Сколько стоит
2) Сколько людей нужно нанять, чтобы обслуживать систему
3) Что он за это получит

Другими словами: Функциональные возможности и их Стоимость. Вопросы блокировок его не интересовали.
Именно что!

А эти вопросы напрямую влияют на масштабируемость системы, на стоимость поддержки и доработок. Тем более что клиент платит не один раз а постоянно.

Ну а, вообще, мне, например, интересен взгляд квалифицированного специалиста со стороны.
Старый 08.10.2019, 12:29   #32  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Цитата:
Сообщение от EVGL Посмотреть сообщение
Извините, что встреваю в эту дискуссию, но вы ведете подсчет ангелов на острие иглы. Была сегодня попытка устроить продажу потенциальному клиенту в соседнем селе. Это, как обычно просветляет. Вопросы, которые интересовали собственника предприятия:
1) Сколько стоит
2) Сколько людей нужно нанять, чтобы обслуживать систему
3) Что он за это получит

Другими словами: Функциональные возможности и их Стоимость. Вопросы блокировок его не интересовали.
Это понятно. Заказчика волнует, получит ли он то что хочет и сколько это будет стоить. И понятно что при продаже нужно обещать как можно больше, а стоимость ставить как можно меньше. Но при выполнении проекта ты должен не то что не уйти в минус, а еще и заработать. А твои затраты зависят как раз от того, на сколько сложно и сколько времени потребуется твоим разработчикам чтобы сделать так как заказчик хочет. А заказчик ко всему новому всегда хочет чтобы а) работало, в том числе, как было (иначе саботажа не избежать) б) работало так как он в себе в голове представлял, когда принял решение что ему нужно поменять систему.

И вот когда ты будешь переворачивать логику так как хочет заказчик и всплывают блокировки и все остальное.
За это сообщение автора поблагодарили: George Nordic (5).
Старый 08.10.2019, 12:30   #33  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Цитата:
Сообщение от Logger Посмотреть сообщение
Затрудняюсь ответить.
Нужно спрашивать тех кто проектировал ядро.
Возможно это делалось для SQL 2000, т.е. для тех случаев когда БД не поддерживает какие-то режимы. Но это только мое предположение.
Когда это проектировали, аксапта еще поддерживала Оракл. Возможно это сказалось.
Да я так и подумал. Но были и есть же новые версии Аксапты. И версионный режим в самом MS SQL. Почему просто его не использовали?
Старый 08.10.2019, 12:33   #34  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,237 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от NitroJunkie Посмотреть сообщение
Да я так и подумал. Но были и есть же новые версии Аксапты. И версионный режим в самом MS SQL. Почему просто его не использовали?
В 2000-м версионного режима не было.
Старый 08.10.2019, 14:11   #35  
trud is offline
trud
Участник
Лучший по профессии 2017
 
792 / 1031 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от NitroJunkie Посмотреть сообщение
Logger, trud. Я может чего-то не понимаю, но ведь это же повторение логики версионников. Зачем это Axapta делает, если можно просто включить Serializable и СУБД в версионном режиме, и СУБД сама кинет update conflict?
АХ сделано так чтобы блокировок не было, в случае SERIALIZABLE они будут (это вообще самый строгий тип блокировок)
Цитата:
SERIALIZABLE
Specifies the following:
Statements cannot read data that has been modified but not yet committed by other transactions.
Доп столбец RecVersion в любой таблице как раз и был добавлен чтобы поддерживать READ_COMMITTED_SNAPSHOT(ON). Я кстати не очень понимаю как можно сделать по другому, в любом другом варианте(т.е. используя UPDATE) вы упретесь что SQL Server не поддерживает блокировку по строкам
Старый 08.10.2019, 14:38   #36  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,509 / 4803 (166) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от NitroJunkie Посмотреть сообщение
Да я так и подумал. Но были и есть же новые версии Аксапты. И версионный режим в самом MS SQL. Почему просто его не использовали?
А вы пробовали стандартным функционалом update conflict в MS SQL пользоваться ?
Просто я сам не пробовал (и вполне возможно что я в этом вопросе не прав), но кто-то из знакомых SQL разработчиков мне рассказывал что в этом режиме тоже есть свои подводные грабли.
Вот например в статье описывают поведение системы при проверке целостности Foreign Keys, и как-то это не очень очевидно.
Старый 08.10.2019, 17:47   #37  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Цитата:
Сообщение от trud Посмотреть сообщение
АХ сделано так чтобы блокировок не было, в случае SERIALIZABLE они будут (это вообще самый строгий тип блокировок)

Доп столбец RecVersion в любой таблице как раз и был добавлен чтобы поддерживать READ_COMMITTED_SNAPSHOT(ON). Я кстати не очень понимаю как можно сделать по другому, в любом другом варианте(т.е. используя UPDATE) вы упретесь что SQL Server не поддерживает блокировку по строкам
Ошибся, имел ввиду на самом деле REPEATABLE READ (в MS SQL - это SNAPSHOT, ну и в Oracle SERIALIZABLE это по сути REPEATABLE READ). Тогда блокировок не будет, а версии записей проверит сам MS SQL.
Старый 08.10.2019, 17:57   #38  
NitroJunkie is offline
NitroJunkie
Участник
 
19 / 28 (1) +++
Регистрация: 03.10.2019
Цитата:
Сообщение от fed Посмотреть сообщение
А вы пробовали стандартным функционалом update conflict в MS SQL пользоваться ?
Просто я сам не пробовал (и вполне возможно что я в этом вопросе не прав), но кто-то из знакомых SQL разработчиков мне рассказывал что в этом режиме тоже есть свои подводные грабли.
Вот например в статье описывают поведение системы при проверке целостности Foreign Keys, и как-то это не очень очевидно.
Я не пользовался MS SQL, но пользовался PostgreSQL (с REPEATABLE READ, аналог SNAPSHOT в MS SQL), где проблемы, с тем что update conflict обнаруживаются для всей записи, а не поколоночно такие же. И все в целом неплохо даже под хорошей нагрузкой.

Foreign keys правда не пользовался (и непонятно зачем в MS SQL вдруг озаботились этой проблемой, когда Write Skew все равно есть, но видимо решили частный случай один поддержать).
Старый 09.10.2019, 00:52   #39  
trud is offline
trud
Участник
Лучший по профессии 2017
 
792 / 1031 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от NitroJunkie Посмотреть сообщение
Ошибся, имел ввиду на самом деле REPEATABLE READ (в MS SQL - это SNAPSHOT, ну и в Oracle SERIALIZABLE это по сути REPEATABLE READ). Тогда блокировок не будет, а версии записей проверит сам MS SQL.
REPEATABLE READ вполне так даст вам блокировки в SQL Server
https://docs.microsoft.com/en-us/sql...ql-server-2017
Цитата:
REPEATABLE READ
Specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes.
Еще раз - мы хотим получить систему без блокировок в общем случае. На чтении это дает только READ_COMMITTED_SNAPSHOT(ON). Но он будет давать блокировки при записи(что как-бы тоже плохо). Поэтому запись сделали в 2 этапа, что потребовало добавление в каждую таблицу столбца RecVersion. (Ну и плюс RecId - уникальный идентификатор записи)
За это сообщение автора поблагодарили: Logger (3).
Старый 09.10.2019, 08:26   #40  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,237 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
NitroJunkie, а чего цитировать документацию?
Есть же запросы.
Запускаем , проверяем блокировки. Времени на это надо 1 минуту.
Теги
1c

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Почти про 1С, а вообще про ПК, Пользователей и ИТ-шников. Lemming Курилка 0 26.02.2005 14:57
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 08:31.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.