В Microsoft SQL Server 2008 R2 были внесены изменения, касающиеся обработки "отравленных" сообщений.
Обычно извлечение сообщений из очереди Service Broker выполняется в одной транзакции с набором других операций, вносящих изменения в базу данных. Например, Вы можете получить сообщение из очереди и добавить запись об этом сообщении в таблицу базы данных. В случае, когда оба этих действия объединены в одной транзакции, Вы получаете гарантию того, что если добавить запись в таблицу по какой-то причине не удалось, то сообщение не будет утеряно. При откате транзакции сообщение будет возвращено в очередь и будет обработано следующей командой RECEIVE.
Если процесс обработки сообщения опять приведет к откату транзакции, то сообщение опять вернется в очередь. При этом, для некоторых сообщений, для которых обработка не может быть выполнена в текущий момент (или вообще никогда) возникает замкнутый цикл (RECEIVE-PROCESSING-FAIL-ROLLBACK)-(RECEIVE....). Такие сообщения известны как отравленные сообщения (poison message).
Отравленные сообщения могут влиять на производительность как конкретного сервиса, так и всего сервера в целом. Существует несколько стратегий для определения и обработки отравленных сообщений. В Service Broker использована достаточно жесткая на мой взгляд стратегия - очередь отключается после пяти откатов транзакций подряд. После чего Вы можете узнать о блокировке очереди через подписку на событие BROKER_QUEUE_DISABLED с помощью CREATE EVENT NOTIFICATION.
Многочисленные жалобы пользователей Microsoft SQL Server Service Broker на такое поведение заставили разработчиков добавить в Microsoft SQL Server 2008 R2 возможность принудительного отключения обработки отравленных сообщений Service Broker. Эти изменения касаются команд создания (CREATE QUEUE) и изменения (ALTER QUEUE) очередей сообщений. В них добавили новую опцию POISON_MESSAGE_HANDLING (STATUS = { ON | OFF }). Согласно описанию, эта опция "позволяет использовать собственную стратегию обработки отравленных сообщений". Использование данной опции не избавит Вас от написания собственной стратегии - она просто отключает блокировку очереди при откате транзакции пять раз подряд.
Обычно извлечение сообщений из очереди Service Broker выполняется в одной транзакции с набором других операций, вносящих изменения в базу данных. Например, Вы можете получить сообщение из очереди и добавить запись об этом сообщении в таблицу базы данных. В случае, когда оба этих действия объединены в одной транзакции, Вы получаете гарантию того, что если добавить запись в таблицу по какой-то причине не удалось, то сообщение не будет утеряно. При откате транзакции сообщение будет возвращено в очередь и будет обработано следующей командой RECEIVE.
Если процесс обработки сообщения опять приведет к откату транзакции, то сообщение опять вернется в очередь. При этом, для некоторых сообщений, для которых обработка не может быть выполнена в текущий момент (или вообще никогда) возникает замкнутый цикл (RECEIVE-PROCESSING-FAIL-ROLLBACK)-(RECEIVE....). Такие сообщения известны как отравленные сообщения (poison message).
Отравленные сообщения могут влиять на производительность как конкретного сервиса, так и всего сервера в целом. Существует несколько стратегий для определения и обработки отравленных сообщений. В Service Broker использована достаточно жесткая на мой взгляд стратегия - очередь отключается после пяти откатов транзакций подряд. После чего Вы можете узнать о блокировке очереди через подписку на событие BROKER_QUEUE_DISABLED с помощью CREATE EVENT NOTIFICATION.
Многочисленные жалобы пользователей Microsoft SQL Server Service Broker на такое поведение заставили разработчиков добавить в Microsoft SQL Server 2008 R2 возможность принудительного отключения обработки отравленных сообщений Service Broker. Эти изменения касаются команд создания (CREATE QUEUE) и изменения (ALTER QUEUE) очередей сообщений. В них добавили новую опцию POISON_MESSAGE_HANDLING (STATUS = { ON | OFF }). Согласно описанию, эта опция "позволяет использовать собственную стратегию обработки отравленных сообщений". Использование данной опции не избавит Вас от написания собственной стратегии - она просто отключает блокировку очереди при откате транзакции пять раз подряд.
Комментариев нет:
Отправить комментарий