Почему не 1С?

[trud]

Цитата:

Сообщение от NitroJunkie

Но в READ COMMITED блокировка же не держится в рамках всей транзакции. Или предполагается что обновление остатков всегда идет ровно одним запросом? И сквозного использования данных в рамках одной транзакции предполагается нет?

В READ COMMITED SNAPSHOT блокировок вообще нет. т.е. в общем случае предполагается что если у вас 2 сессии меняют одно и тоже, то у вас что-то не в порядке с бизнес процессами и одна из сессий при попытке сохранения записи получит сообщение о ошибке - "Запись изменена другим пользователем, обновите форму".
Есть еще много частных случаев - например в случае остатков, они не меняются при обработке документа, вместо этого создается лог изменений и по событию окончания транзакции этот лог записывается в основную таблицу.
Вот еще несколько частных случаев - https://denistrunin.com/understanding-sql-blocking

[NitroJunkie]

Цитата:

Сообщение от trud

В READ COMMITED SNAPSHOT блокировок вообще нет. т.е. в общем случае предполагается что если у вас 2 сессии меняют одно и тоже, то у вас что-то не в порядке с бизнес процессами и одна из сессий при попытке сохранения записи получит сообщение о ошибке - "Запись изменена другим пользователем, обновите форму".
Есть еще много частных случаев - например в случае остатков, они не меняются при обработке документа, вместо этого создается лог изменений и по событию окончания транзакции этот лог записывается в основную таблицу.
Вот еще несколько частных случаев - https://denistrunin.com/understanding-sql-blocking

Я знаю, что такое READ COMMITED SNAPSHOT. Речь о том, что если например сделать сначала select во временную таблицу (или написать while select), а только потом update, то если уровень изоляции не RR (ставится блокировка или проверяется update conflict), может получится некорректный показатель из-за non-repeatable read.

[trud]

Не понял фразы "некорректный показатель". Возможно надо обсудить пример.
Но вся система на этом построена, проблемы с некорректностью чего-то я даже и не припомню. Repeatable Read будет блокировать сессии, АХ так не работает

[NitroJunkie]

Цитата:

Сообщение от 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

[Logger]

Если коротко, то в Аксапте есть
1. пессимистическая модель обновления (используется редко) когда блокировка ставится в момент выборки на select и тогда никто не вклинится в вашем примере а повиснет в блокировке.
2. оптимистическая модель обновления (это основной случай) когда блокировка ставится только в момент обновления. Тогда ваши опасения обоснованы. Но в Аксапте для этого есть защита. в каждой записи есть поле RecVersion которое меняется при каждом обновлении на другое псевдослучайное значение. И аксапта при выполнении обновления проверяет сохранилось ли это значение на момент обновления таким же как было при выборке, если не сохранилось значит кто-то другой уже влез (то чего вы боитесь) и тогда ядро аксапты выбрасывает исключение "конфликт обновления записей" и либо идет обработка этой ситуации программистом X++ либо идет откат транзакции.

Это все работает внутри открытой транзакции в режиме Read committed

[trud]

Ну с 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) и далее на завершении транзакции этот лог перепишется в таблицу балансов

[Logger]

Вот пример джоба по работе с разными типами блокировок

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);
}

для случая оптимистичной модели будут такие запросы:

SELECT A.ITEMID, ... A.RECVERSION,A.RECID 
FROM INVENTTABLE A 
WHERE ((DATAAREAID=N'MRC') AND (ITEMID=N'0000001'))

/* блокировки не накладывается */

UPDATE INVENTTABLE SET NAMEALIAS=?,RECVERSION=?,MODIFIEDDATE=?,MODIFIEDTIME=?,MODIFIEDBY=? 
WHERE (((DATAAREAID=?) AND (RECID=?)) AND (RECVERSION=?))

/* блокировка накладывается, но добавлено условие на RECVERSION - если другая сессия успела влезть и поменять данные то тогда в базе будет другой RecVersion и наш запрос обновить 0 записей. Ядро этой поймет и бросит исключение Exception::UpdateConflict - которое мы на X++ сможем обработать */


для случая пессимистичной модели будут такие запросы:

SELECT  A.ITEMID, ... A.RECVERSION,A.RECID 
FROM INVENTTABLE A WITH( UPDLOCK)
WHERE ((DATAAREAID=N'MRC') AND (ITEMID=N'0000001'))

/* блокировка накладывается из-за явного указания WITH( UPDLOCK) */

UPDATE INVENTTABLE SET NAMEALIAS=?,RECVERSION=?,MODIFIEDDATE=?,MODIFIEDTIME=?,MODIFIEDBY=? 
WHERE ((DATAAREAID=?) AND (RECID=?))

/* блокировка уже есть. Обновляем запись, ее все равно никто не трогал из-за блокировки */



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

[NitroJunkie]

Logger, trud. Я может чего-то не понимаю, но ведь это же повторение логики версионников. Зачем это Axapta делает, если можно просто включить Serializable и СУБД в версионном режиме, и СУБД сама кинет update conflict?

[Logger]

Затрудняюсь ответить.
Нужно спрашивать тех кто проектировал ядро.
Возможно это делалось для SQL 2000, т.е. для тех случаев когда БД не поддерживает какие-то режимы. Но это только мое предположение.
Когда это проектировали, аксапта еще поддерживала Оракл. Возможно это сказалось.

[EVGL]

Извините, что встреваю в эту дискуссию, но вы ведете подсчет ангелов на острие иглы. Была сегодня попытка устроить продажу потенциальному клиенту в соседнем селе. Это, как обычно просветляет. Вопросы, которые интересовали собственника предприятия:
1) Сколько стоит
2) Сколько людей нужно нанять, чтобы обслуживать систему
3) Что он за это получит

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

[Logger]

Цитата:

Сообщение от EVGL

Вопросы, которые интересовали собственника предприятия:
1) Сколько стоит
2) Сколько людей нужно нанять, чтобы обслуживать систему
3) Что он за это получит

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

Именно что!

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

Ну а, вообще, мне, например, интересен взгляд квалифицированного специалиста со стороны.

[NitroJunkie]

Цитата:

Сообщение от EVGL

Извините, что встреваю в эту дискуссию, но вы ведете подсчет ангелов на острие иглы. Была сегодня попытка устроить продажу потенциальному клиенту в соседнем селе. Это, как обычно просветляет. Вопросы, которые интересовали собственника предприятия:
1) Сколько стоит
2) Сколько людей нужно нанять, чтобы обслуживать систему
3) Что он за это получит

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

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

И вот когда ты будешь переворачивать логику так как хочет заказчик и всплывают блокировки и все остальное.

[NitroJunkie]

Цитата:

Сообщение от Logger

Затрудняюсь ответить.
Нужно спрашивать тех кто проектировал ядро.
Возможно это делалось для SQL 2000, т.е. для тех случаев когда БД не поддерживает какие-то режимы. Но это только мое предположение.
Когда это проектировали, аксапта еще поддерживала Оракл. Возможно это сказалось.

Да я так и подумал. Но были и есть же новые версии Аксапты. И версионный режим в самом MS SQL. Почему просто его не использовали?

[Logger]

Цитата:

Сообщение от NitroJunkie

Да я так и подумал. Но были и есть же новые версии Аксапты. И версионный режим в самом MS SQL. Почему просто его не использовали?

В 2000-м версионного режима не было.

[trud]

Цитата:

Сообщение от 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 не поддерживает блокировку по строкам

[fed]

Цитата:

Сообщение от NitroJunkie

Да я так и подумал. Но были и есть же новые версии Аксапты. И версионный режим в самом MS SQL. Почему просто его не использовали?

А вы пробовали стандартным функционалом update conflict в MS SQL пользоваться ?
Просто я сам не пробовал (и вполне возможно что я в этом вопросе не прав), но кто-то из знакомых SQL разработчиков мне рассказывал что в этом режиме тоже есть свои подводные грабли.
Вот например в статье описывают поведение системы при проверке целостности Foreign Keys, и как-то это не очень очевидно.

[NitroJunkie]

Цитата:

Сообщение от trud

АХ сделано так чтобы блокировок не было, в случае SERIALIZABLE они будут (это вообще самый строгий тип блокировок)

Доп столбец RecVersion в любой таблице как раз и был добавлен чтобы поддерживать READ_COMMITTED_SNAPSHOT(ON). Я кстати не очень понимаю как можно сделать по другому, в любом другом варианте(т.е. используя UPDATE) вы упретесь что SQL Server не поддерживает блокировку по строкам

Ошибся, имел ввиду на самом деле REPEATABLE READ (в MS SQL - это SNAPSHOT, ну и в Oracle SERIALIZABLE это по сути REPEATABLE READ). Тогда блокировок не будет, а версии записей проверит сам MS SQL.

[NitroJunkie]

Цитата:

Сообщение от fed

А вы пробовали стандартным функционалом update conflict в MS SQL пользоваться ?
Просто я сам не пробовал (и вполне возможно что я в этом вопросе не прав), но кто-то из знакомых SQL разработчиков мне рассказывал что в этом режиме тоже есть свои подводные грабли.
Вот например в статье описывают поведение системы при проверке целостности Foreign Keys, и как-то это не очень очевидно.

Я не пользовался MS SQL, но пользовался PostgreSQL (с REPEATABLE READ, аналог SNAPSHOT в MS SQL), где проблемы, с тем что update conflict обнаруживаются для всей записи, а не поколоночно такие же. И все в целом неплохо даже под хорошей нагрузкой.

Foreign keys правда не пользовался (и непонятно зачем в MS SQL вдруг озаботились этой проблемой, когда Write Skew все равно есть, но видимо решили частный случай один поддержать).

[trud]

Цитата:

Сообщение от 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]

NitroJunkie, а чего цитировать документацию?
Есть же запросы.
Запускаем , проверяем блокировки. Времени на это надо 1 минуту.