Denis Trunin's Blogs: Blocking in D365FO(and why you shouldn't always follow MS recommendations)

[skuull]

Цитата:

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

ну в общем случае select forupdate не блокируется.Исключение составляет эскаляция блокировок, но это уже другая тема

Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?

[fed]

Цитата:

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

Это та же самая тема. Вопрос эскалации встает при больших количествах данных\пользователей\потоков и говорить "тут больше 1-2х строк не будет" звучит не убидительно. Сегодня нет, а завтра поменяется бизнес процесс и их будет тысячи, что сядем все переписывать?

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

[skuull]

Цитата:

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

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

Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители

[fed]

Цитата:

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

Так я экспертом в вопросе блокировок не являюсь и считаю что самовыдвигаться в эксперты как-то не очень, хотя есть любители

А если Вы "экспертом по теме блокировок не являетесь", то откуда этой теме 12 Ваших постов (и кажется еще в твиттере сколько-то, но там мне как-то лень считать)?
Может это троллинг был ? Не может такого быть, просто не могу поверить...

[Vadik]

Цитата:

Сообщение от 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 или на основе каких-то городских мифов), мало кто проверяет как они работают

[ax_mct]

Цитата:

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

Много кто делает "правильно" (по BP или на основе каких-то городских мифов), мало кто проверяет как они работают

Более-менее правильно делают те кто начал с ранних версий. Потому как потом смотрят на дичь в стандартном коде 2012 куда слили левый код как он был и просто не понимают как правильно.

Цитата:

зачем делать медленнее если можно быстрее?

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

Цитата:

Нельзя жертвовать скоростью в угоду возможным идиотам

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