Длительные операции внутри транзакции могут привести к проблемам параллельности работы пользователей, в данной статье мы диагностируем эту проблему и разрешим ее.
Во время мониторинга системы, по технологическому журналу были обнаружены управляемые блокировки (TLOCK) время ожидания которых оказалось очень большим (вплоть до 12 секунд) и, в результате этого всего, 0,015% управляемых блокировок провели около 70% времени в ожидании на блокировках.
Это, несомненно, является очень подозрительным и требует анализа поскольку такие длительные ожидания недопустимы. Например, при настройках по умолчанию, таймаут срабатывает при 20 секундах ожидания и, не ровен час, в системе начнут появляться события TTIMEOUT. Итак, нам необходимо расследовать причину таких длительных ожиданий.
К данной ситуации привела ошибка в коде, связанная с вызовом длительной операции внутри транзакции — отправкой электронного письма, время которой могло занимать порядка 5-10 секунд (что коррелирует с времени ожидания на блокировке) а также исключительной блокировкой записи регистра. Во время работы системы, при возникновении определенного события, несколько сеансов практически одновременно пытались наложить одинаковую управляемую блокировку. После того как первый из сеансов устанавливал ее, он держал данную блокировку до окончания транзакции, длительность которой занимала существенное время.
Для устранения данной проблемы было принято решение разделить задачу на этапы:
- При записи транспортного сообщения вносить запись в регистр сведений «УведомленияПоОбъектам1СОтчетность» с пустыми свойствами «УведомлениеСформировано» и «ДатаОповещения», которые являются признаком того что транспортное сообщение было получено, но не было отправлено уведомление пользователям.
- Периодически (например, каждые 5 минут) регламентным заданием проверять наличие записей, по которым не было отправлено письмо (УведомлениеСформировано = Ложь) и высылать его, делая об этом отметку в регистре сведений в случае успеха.
Как результат, такие длительные TLOCK были устранены.