Почему не 1С?

[NitroJunkie]

Цитата:

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

REPEATABLE READ вполне так даст вам блокировки в SQL Server
https://docs.microsoft.com/en-us/sql...ql-server-2017

Еще раз - мы хотим получить систему без блокировок в общем случае. На чтении это дает только READ_COMMITTED_SNAPSHOT(ON). Но он будет давать блокировки при записи(что как-бы тоже плохо). Поэтому запись сделали в 2 этапа, что потребовало добавление в каждую таблицу столбца RecVersion. (Ну и плюс RecId - уникальный идентификатор записи)

Я знаю что REPEATABLE_READ дает блокировки (так как MS SQL по умолчанию блокировочник). Но в MS SQL уже давно сделали версионный режим и соответствующий уровень изоляции - SNAPSHOT, который соответствует REPEATABLE_READ в PostgreSQL, и SERIALIZABLE в Oracle. То есть можно включить уровень изоляции SNAPSHOT и MS SQL сам будет проверять версии записей и кидать update conflict'ы. И это будет по идее ровно то что делает Axapta на прикладном уровне (и по идее быстрее).

Блокировок при этом не будет (в этом собственно и смысл версионного режима).

[Logger]

Еще одна версия, почему так сделано - версионный режим потребляет больше ресурсов и работает медленнее. Возможно это тоже сказалось.

[NitroJunkie]

Цитата:

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

Еще одна версия, почему так сделано - версионный режим потребляет больше ресурсов и работает медленнее. Возможно это тоже сказалось.

Тут да, есть нюанс что в MS SQL такой режим реализован не нативно. Но уровень изоляции READ_COMMITED_SNAPSHOT то используется (это тот же SNAPSHOT но на одной команде). Ну и вряд ли это медленнее, чем обеспечивать версионность на прикладном уровне.

[Владимир Максимов]

Цитата:

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

То есть можно включить уровень изоляции SNAPSHOT и MS SQL сам будет проверять версии записей и кидать update conflict'ы. И это будет по идее ровно то что делает Axapta на прикладном уровне (и по идее быстрее).

Блокировок при этом не будет (в этом собственно и смысл версионного режима).

О режимах изоляции в MS SQL имеет смысл говорить только в рамках открытой транзакции. Если транзакции нет, то и разговаривать не о чем

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

Да и разрешение конфликта - это тоже перезапрос. При этом не конкретной записи, а вообще всего снимка. Т.е. вообще всех отображенных данных.

Как-то это все слишком накладно получается...


Режим изоляции - это не есть глобальный режим работы SQL. Это "ситуационная" (сиюминутная) настройка. Даже не соединения, а одной конкретной транзакции. Может быть изменена в рамках одной процедуры несколько раз.

Да, возможна настройка по умолчанию. Но! По прежнему в рамках транзакции. А приложение так не работает. Операция чтения, как правило, сильно отдалена от операции записи по времени. По этой причине включить их в одну транзакцию просто невозможно.

Можно, конечно, использовать этот прием именно в процедурах. Но стоит ли реализовывать два принципиально разных механизма разрешения конфликтов совместного доступа в рамках одного приложения?