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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 31.01.2019, 13:45   #1  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
700 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
ну в общем случае select forupdate не блокируется.Исключение составляет эскаляция блокировок, но это уже другая тема
Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?
Старый 31.01.2019, 13:56   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?
Могу подсказать простой выход - напиши в своем блоге полноценный пост на эту тему, с разбором всех ситуаций, своими экспертными рекомендациями и тд и тп.
А мы потом, по возможности, тоже поищем в нем ошибки и слегонца постебемся.
Старый 31.01.2019, 21:17   #3  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
700 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Могу подсказать простой выход - напиши в своем блоге полноценный пост на эту тему, с разбором всех ситуаций, своими экспертными рекомендациями и тд и тп.
А мы потом, по возможности, тоже поищем в нем ошибки и слегонца постебемся.
Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители
Старый 01.02.2019, 15:20   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители
А если Вы "экспертом по теме блокировок не являетесь", то откуда этой теме 12 Ваших постов (и кажется еще в твиттере сколько-то, но там мне как-то лень считать)?
Может это троллинг был ? Не может такого быть, просто не могу поверить...
За это сообщение автора поблагодарили: skuull (0).
Старый 01.02.2019, 17:00   #5  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1853 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от fed Посмотреть сообщение
А если Вы "экспертом по теме блокировок не являетесь", то откуда этой теме 12 Ваших постов (и кажется еще в твиттере сколько-то, но там мне как-то лень считать)?
Денис, пятница же, добрее надо как-то

Цитата:
Сообщение от trud
Пример 1 - индекс по полю Field2, update_recordset по поля Field2 и Field3. получаем блокировку (которой не было при select forupdate)

Пример 2 - индекс по полю Field2,Field3 update_recordset первой сессии по полям Field2 и Field3, второй сессии по Field2, Field4 получаем блокировку (которой опять же не было при select forupdate)
Ну да, блокировки ключа индекса как при update_recordset не происходит, зато блокировка на уже обновленные записи удерживается дольше. Причем если deadlock при update_recordset лечится банальным retry, то с длинной транзакцией бороться уже немного сложнее. Насколько в Вашем сценарии типично конкурентное обновление одних и тех же данных и какой подход в итоге даст лучшую производительность (throughput) - без тестирования заранее сказать нельзя

Я это к чему - нет здесь универсальных рекомендаций и "правильных" решений. Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 01.02.2019 в 17:03.
Старый 01.02.2019, 17:44   #6  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Vadik Посмотреть сообщение
Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают
Более-менее правильно делают те кто начал с ранних версий. Потому как потом смотрят на дичь в стандартном коде 2012 куда слили левый код как он был и просто не понимают как правильно.

Цитата:
зачем делать медленнее если можно быстрее?
Не надо делать быстрее пока не нужно. Даже если можно

Цитата:
Нельзя жертвовать скоростью в угоду возможным идиотам
Нужно жертвовать. Потому как через пару месяцев смотришь на свой же оптимизированный код полным идиотом
Maintenance comes first. А в оптимизированном коде фиг подебажишь нормально.

Последний раз редактировалось ax_mct; 01.02.2019 в 17:52.
За это сообщение автора поблагодарили: trud (1).
Теги
#покормитроля, как правильно, производительность

 

Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:45.