AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.04.2006, 18:01   #1  
kitty is offline
kitty
Участник
 
342 / 23 (1) +++
Регистрация: 24.05.2005
уровни изоляции
Привет
вопрос навеян топиком: Как посмотреть уровень изоляции , где написано:

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

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

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

Экперимент у меня (ах2.5) показал,что так оно и есть получается..
Имеем, что каждый чих надо обертывать в транзакции иначе можно наиметь неприятностей ?
Старый 07.04.2006, 10:33   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,254 / 2155 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Если не ошибаюсь, то вне транзакции Аксапта может послать на сиквел хинт noLock даже если мы явно не прописали его в запросе. Это верно для каких-то типов кеширования таблиц. Для каких именно не помню. Можно просто поэкспериментировать и проверить.
Старый 07.04.2006, 10:36   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,254 / 2155 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от kitty
Имеем, что каждый чих надо обертывать в транзакции иначе можно наиметь неприятностей ?
Ну по идее при запросах на изменение - данные на основе которых мы формируем наши изменения - надо выбирать в транзакции. В этом вы правы.

Просто большинство запросов идет не на обновление данных а просто на чтение. И хинт NoLock в таком случае очень полезен для MS SQL - меньше блокировок.
Старый 07.04.2006, 13:08   #4  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,374 / 454 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Имеем, что каждый чих надо обертывать в транзакции иначе можно наиметь неприятностей ?
Не на каждый чих, а только там, где нам важна согласованность по чтению. По идее, при изменении данных из одного сеанса (а точнее при select forupdate) устанавливается эксклюзивная блокировка (X). Уровень изоляции read uncommitted позволяет второму сеансу читать данные, на которые наложена X-блокировка. Оборачивая наш код в ttsbegin...tts(commit)/(abort) мы говорим SQL Server-у установить еще одну X-блокировку. А так, как две X-блокировки между собой не совместимы, мы гарантированно читаем только подтвержденные данные.
Старый 07.04.2006, 14:36   #5  
kitty is offline
kitty
Участник
 
342 / 23 (1) +++
Регистрация: 24.05.2005
Получается, что когда мы используем в классе вызываемом по кнопке с формы (чо-нить вычисляющий) args.record(), то по идее надо каждый раз в этом классе внутри транзакции перевыбирать эту запись, так как попасть иначе в расчеты могут абсолютно непредсказаемые данные .....
Старый 07.04.2006, 14:49   #6  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,374 / 454 (20) +++++++
Регистрация: 03.12.2001
Цитата:
надо каждый раз
Не каждый раз. А только в том случае, когда чтение "грязных данных" является очень нежелательным. И потом, у вас часто rollback в системе происходит?
Старый 07.04.2006, 15:45   #7  
kitty is offline
kitty
Участник
 
342 / 23 (1) +++
Регистрация: 24.05.2005
поразвожу демагогию касательно rollback:
как оценить часто они происходят или нет?
инструментов таких в sql server я не знаю(ну если не анализировать всей базы )... Но даже если бы и был , то был бы не показательным. Просто чисто rollback нам ничего не говорит. Даже если его сравнить с общим количеством транзакции за тот же промежуток времени. Чтобы это было показательным, надо было бы смотреть не просто количество rollback-ов , а число таких rollback, что есть/были другие транзакции претендовавшие или использовавшие ресурсы(в первую очередь таблицы), которых касалась та транзакция, в которой произошел rollback...Тогда можно оценить на сколько существенную роль может играть грязное чтение.
Но так как это на сколько я понимаю не реально, то могу просто поискать по aot вызовы throw error(хотя, как выбрать только те, что в трензакциях) и ttsabort.Но тут еще роль будет играть то, в каком функционале они прописаны и сколько пользователей обычно пользуются одновременно теми таблицами, что используются в этом куске кода, даже если и из другого функционала.
Это мне тоже представляется нереальным.


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

Единственное, что хотелось бы уточнить, на больших внедрениях с большим количеством пользователей, часто возникают ошибки, связанные с упомянутым выше "грязным чтением" или все солнечно и приятно работает?
Старый 07.04.2006, 15:46   #8  
kitty is offline
kitty
Участник
 
342 / 23 (1) +++
Регистрация: 24.05.2005
"ну если не анализировать всей базы "
слдеует читать: "ну если не анализировать логи всей базы"
(в предыдущем посте накосячила )
Старый 07.04.2006, 15:58   #9  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,368 / 2558 (94) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от Андре
Оборачивая наш код в ttsbegin...tts(commit)/(abort) мы говорим SQL Server-у установить еще одну X-блокировку.
По идее X должен быть только при forUpdate а если просто чтение, то S - разве не так?
__________________
https://axcoder.github.io
За это сообщение автора поблагодарили: alex55 (1).
Старый 07.04.2006, 16:04   #10  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,374 / 454 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Единственное, что хотелось бы уточнить, на больших внедрениях с большим количеством пользователей, часто возникают ошибки, связанные с упомянутым выше "грязным чтением" или все солнечно и приятно работает?
Ошибок с грязным чтением, насколько я помню, не встречал. А вот с проблемами взаимоблокировок, вызванных неаккуратным использованием транзакций сталкивался и не раз.

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

Цитата:
И потом, у вас часто rollback в системе происходит?
Общие рассуждения: в грамотно спроектированной системе откат транзакции не такое уж и частое явление, подавляющая часть чтение в Аксапте связана с выводом данных на пользовательские формы, а не с бизнес логикой, а следовательно, грязные чтения в этом случае не критичны для работы системы.
В общем, поэтому то я и писал о том, что "применять транзакции на каждый чих" не стоит.
Старый 07.04.2006, 16:12   #11  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,374 / 454 (20) +++++++
Регистрация: 03.12.2001
Цитата:
По идее X должен быть только при forUpdate а если просто чтение, то S - разве не так?
Ага. Спасибо, это я уже не так написал. Но сути дела это не меняет - S и X не совместимы.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Можно-ли установить уровень изоляции транзакции ? egorych DAX: Программирование 12 14.09.2007 14:17
Как посмотреть уровень изоляции DarkBear DAX: Администрирование 17 28.07.2005 11:31
OLAP. Как "обновить" уровни? NJD DAX: Функционал 1 07.07.2005 16:39
Минимальные уровни запасов помесячно axot DAX: Функционал 11 28.10.2002 13:35
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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