Почему не 1С?

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

[NitroJunkie]

Цитата:

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

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

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

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

[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 - уникальный идентификатор записи)

[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 на прикладном уровне (и по идее быстрее).

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

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

Цитата:

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

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

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

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

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

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

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


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

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

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