уровни изоляции

[kitty]

Привет
вопрос навеян топиком: Как посмотреть уровень изоляции , где написано:

Цитата:

Для чтения данных в формах (визуализация средствами ядра) обычно используется SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Для чтения данных в транзакции (в коде) обычно используется SET TRANSACTION ISOLATION LEVEL READ COMMITTED, если хинта NOLOCK не было.

и не "отлавливать", а фильтр поставить... В мониторе...
"

То есть я правильно понимаю, что в Ax коде по умолчанию разрешено грязное чтение? То есть кто-то там что -то изменяет в транзакции, я читаю преспокойненько эти данные в своем коде, а потом у этого кого-то транзакция откатывается и мои данные как бы так помягче выразиться некорректны ....

Экперимент у меня (ах2.5) показал,что так оно и есть получается..
Имеем, что каждый чих надо обертывать в транзакции иначе можно наиметь неприятностей ?

[Logger]

Если не ошибаюсь, то вне транзакции Аксапта может послать на сиквел хинт noLock даже если мы явно не прописали его в запросе. Это верно для каких-то типов кеширования таблиц. Для каких именно не помню. Можно просто поэкспериментировать и проверить.

[Logger]

Цитата:

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

Имеем, что каждый чих надо обертывать в транзакции иначе можно наиметь неприятностей ?

Ну по идее при запросах на изменение - данные на основе которых мы формируем наши изменения - надо выбирать в транзакции. В этом вы правы.

Просто большинство запросов идет не на обновление данных а просто на чтение. И хинт NoLock в таком случае очень полезен для MS SQL - меньше блокировок.

[Андре]

Цитата:

Имеем, что каждый чих надо обертывать в транзакции иначе можно наиметь неприятностей ?

Не на каждый чих, а только там, где нам важна согласованность по чтению. По идее, при изменении данных из одного сеанса (а точнее при select forupdate) устанавливается эксклюзивная блокировка (X). Уровень изоляции read uncommitted позволяет второму сеансу читать данные, на которые наложена X-блокировка. Оборачивая наш код в ttsbegin...tts(commit)/(abort) мы говорим SQL Server-у установить еще одну X-блокировку. А так, как две X-блокировки между собой не совместимы, мы гарантированно читаем только подтвержденные данные.

[kitty]

Получается, что когда мы используем в классе вызываемом по кнопке с формы (чо-нить вычисляющий) args.record(), то по идее надо каждый раз в этом классе внутри транзакции перевыбирать эту запись, так как попасть иначе в расчеты могут абсолютно непредсказаемые данные .....

[Андре]

Цитата:

надо каждый раз

Не каждый раз. А только в том случае, когда чтение "грязных данных" является очень нежелательным. И потом, у вас часто rollback в системе происходит?

[kitty]

поразвожу демагогию касательно rollback:
как оценить часто они происходят или нет?
инструментов таких в sql server я не знаю(ну если не анализировать всей базы )... Но даже если бы и был , то был бы не показательным. Просто чисто rollback нам ничего не говорит. Даже если его сравнить с общим количеством транзакции за тот же промежуток времени. Чтобы это было показательным, надо было бы смотреть не просто количество rollback-ов , а число таких rollback, что есть/были другие транзакции претендовавшие или использовавшие ресурсы(в первую очередь таблицы), которых касалась та транзакция, в которой произошел rollback...Тогда можно оценить на сколько существенную роль может играть грязное чтение.
Но так как это на сколько я понимаю не реально, то могу просто поискать по aot вызовы throw error(хотя, как выбрать только те, что в трензакциях) и ttsabort.Но тут еще роль будет играть то, в каком функционале они прописаны и сколько пользователей обычно пользуются одновременно теми таблицами, что используются в этом куске кода, даже если и из другого функционала.
Это мне тоже представляется нереальным.


По идее, наверное, вопрос исчерпан... Всем спасибо за разъяснения.

Единственное, что хотелось бы уточнить, на больших внедрениях с большим количеством пользователей, часто возникают ошибки, связанные с упомянутым выше "грязным чтением" или все солнечно и приятно работает?

[kitty]

"ну если не анализировать всей базы "
слдеует читать: "ну если не анализировать логи всей базы"
(в предыдущем посте накосячила )

[belugin]

Цитата:

Сообщение от Андре

Оборачивая наш код в ttsbegin...tts(commit)/(abort) мы говорим SQL Server-у установить еще одну X-блокировку.

По идее X должен быть только при forUpdate а если просто чтение, то S - разве не так?

[Андре]

Цитата:

Единственное, что хотелось бы уточнить, на больших внедрениях с большим количеством пользователей, часто возникают ошибки, связанные с упомянутым выше "грязным чтением" или все солнечно и приятно работает?

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

Собственно, я к этому и задал свой вопрос:

Цитата:

И потом, у вас часто rollback в системе происходит?

Общие рассуждения: в грамотно спроектированной системе откат транзакции не такое уж и частое явление, подавляющая часть чтение в Аксапте связана с выводом данных на пользовательские формы, а не с бизнес логикой, а следовательно, грязные чтения в этом случае не критичны для работы системы.
В общем, поэтому то я и писал о том, что "применять транзакции на каждый чих" не стоит.

[Андре]

Цитата:

По идее X должен быть только при forUpdate а если просто чтение, то S - разве не так?

Ага. Спасибо, это я уже не так написал. Но сути дела это не меняет - S и X не совместимы.