Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
хочу сделать следующее:
создать очередь и писать в неё что-то типа лога, отправлять сообщения в триггерах, процедурах и т.д..

Если в процедуре или триггере просто добавлять записи в свою лог таблицу, то при откате транзакции эти записи также откатываются.

Мож ли делать так:

процедура
начало транзакции
отправка сообщения1 в очередь
...
отправка сообщения2 в очередь

...
отправка сообщенияN в очередь
..
коммит 
или 
откат

если процедура (или триггер) откатит транзакцию, в которой отправлялись сообщения в очередь, то дойдут ли сообщения до обработчика?

Т.е. не подействует ли откат на них?
22 июл 09, 10:05    [7443496]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Нет, не дойдут, ибо сообщения сервис брокера подтранзакционны.
22 июл 09, 10:21    [7443596]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
pkarklin
Нет, не дойдут, ибо сообщения сервис брокера подтранзакционны.


т.е. в моем примере сообщения попадут в очередь только после коммита?
22 июл 09, 10:47    [7443808]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Winnipuh
т.е. в моем примере сообщения попадут в очередь только после коммита?


Документацию, понимаю, читать не модно:

The foundation of the Service Broker programming model is transactional messaging. Any operation that involves Service Broker is part of the current transaction. Service Broker does not commit a messaging operation until the current transaction commits. If the transaction rolls back, the Database Engine guarantees that all messaging operations that are part of the transaction also roll back. An application manages messaging operations as part of managing SQL Server transactions.
22 июл 09, 11:23    [7444087]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
тогда остается вопрос - как организовать журнал, в который будут добавлять записи независимо от того, роллбэкнулась транзакция или нет.
Т.е добавлять записи, чтобы знать, что произошло особенно в случае роллбэков...
22 июл 09, 11:46    [7444256]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Winnipuh
тогда остается вопрос - как организовать журнал, в который будут добавлять записи независимо от того, роллбэкнулась транзакция или нет.
Т.е добавлять записи, чтобы знать, что произошло особенно в случае роллбэков...


У MS SQL нет автономных транзакций, которые бы позволили реализовать желаемое в рамках одной транзакции. Использование CLR процедур с отдельным коннектом, думаю, сможет помочь.
22 июл 09, 11:51    [7444297]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
pkarklin
Winnipuh
тогда остается вопрос - как организовать журнал, в который будут добавлять записи независимо от того, роллбэкнулась транзакция или нет.
Т.е добавлять записи, чтобы знать, что произошло особенно в случае роллбэков...


У MS SQL нет автономных транзакций, которые бы позволили реализовать желаемое в рамках одной транзакции. Использование CLR процедур с отдельным коннектом, думаю, сможет помочь.


хмм.. интересная идея... Т.е. вызвать в процедуре SQLCLR процедуру, которая установит свой коннект и добавит запись в таблицу....

А разве в данном случае SQLCLR не будет выполняться в той же транзакции, что и вызывающая процедура?
22 июл 09, 12:03    [7444384]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5499
Блог
Winnipuh,

Если делать неконтекстное соединение и установить enlist=false, то будет отдельная транзакция.
22 июл 09, 12:11    [7444438]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
DeColo®es
Winnipuh,

Если делать неконтекстное соединение и установить enlist=false, то будет отдельная транзакция.


шайтан!
22 июл 09, 12:55    [7444748]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
DeColo®es
Winnipuh,

Если делать неконтекстное соединение и установить enlist=false, то будет отдельная транзакция.


как установить такой коннект, точнее как узнать сервер, базу, чтобы автоматом установить
коннекцию, а не хардкодировать?
22 июл 09, 20:18    [7447668]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5499
Блог
Самое эффективное - передавать в виде параметров в функцию сборки при вызове. :)
24 июл 09, 11:34    [7455318]     Ответить | Цитировать Сообщить модератору
 Re: Снова о Брокерских очередях  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
DeColo®es
Самое эффективное - передавать в виде параметров в функцию сборки при вызове. :)


да, видимо лучший выход.
24 июл 09, 11:50    [7455458]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить