Commit 58a08048 authored by dwentzel's avatar dwentzel

added file

parent 7233ba20
/*
This is the source code for http://www.davewentzel.com/content/service-broker-demystified-can-i-model-monologs-yes-you-can.
This covers what happens with the fire-and-forget (monolog) pattern.
*/
--basic setup
USE master
GO
CREATE DATABASE SBTest
GO
ALTER DATABASE SBTest SET NEW_BROKER
GO
USE SBTest
GO
--let's set up a basic sender and receiver
CREATE QUEUE SenderQ;
CREATE QUEUE ReceiverQ;
CREATE SERVICE SenderSvc ON QUEUE SenderQ;
CREATE SERVICE ReceiverSvc ON QUEUE ReceiverQ ([DEFAULT]);
--note that we send the message and immediately END CONVERSATION
--this is OK, but it violates the rule that the Target always
--ends the conversation first.
BEGIN TRANSACTION
DECLARE @h UNIQUEIDENTIFIER;
BEGIN DIALOG @h
FROM SERVICE [SenderSvc]
TO SERVICE 'ReceiverSvc'
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @h ('Start MyProc Asynchronously');
END CONVERSATION @h;
COMMIT;
--everything seems ok so far
select message_body, transmission_status from sys.transmission_queue
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from SenderQ
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from ReceiverQ
--now receiver processes the message
BEGIN TRAN
DECLARE @rh UNIQUEIDENTIFIER;
WAITFOR(
RECEIVE
TOP(1) @rh = conversation_handle
FROM ReceiverQ
), TIMEOUT 2000 ;
--call the stored procedure here and then END CONVERSATION
END CONVERSATION @rh;
COMMIT
GO
--everything is still ok...so it looks like the sender can actually END CONVERSATION first
select message_body, transmission_status from sys.transmission_queue
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from SenderQ
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from ReceiverQ
--but now let's assume we attach a contract and message type to the ReceiverSvc in the next release
--but we forget to modify the SenderSvc messages to now be validate XML
CREATE MESSAGE TYPE MyNewMT VALIDATION = WELL_FORMED_XML;
CREATE CONTRACT MyNewContract (MyNewMT SENT BY INITIATOR);
ALTER SERVICE ReceiverSvc (ADD CONTRACT MyNewContract);
SELECT 'Contract was added'
--but what happens if the stored proc starts to throw errors...let's see
--send another message
BEGIN TRANSACTION
DECLARE @h UNIQUEIDENTIFIER;
BEGIN DIALOG @h
FROM SERVICE [SenderSvc]
TO SERVICE 'ReceiverSvc'
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @h ('Start MyProc Asynchronously');
END CONVERSATION @h;
COMMIT;
--everything is still ok
select message_body, transmission_status from sys.transmission_queue
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from SenderQ
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from ReceiverQ
--now receiver processes the message, but it should throw errors
BEGIN TRAN
DECLARE @rh UNIQUEIDENTIFIER;
WAITFOR(
RECEIVE
TOP(1) @rh = conversation_handle
FROM ReceiverQ
), TIMEOUT 2000 ;
END CONVERSATION @rh;
COMMIT
GO
--note that there are no errors in ANY of the queues. The error is lost forever.
--this is because the Sender told SSB that it wasn't interested in seeing any messages
--(including errors) from the ReceiverSvc.
--Bad idea!!!!!!
select message_body, transmission_status from sys.transmission_queue
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from SenderQ
select conversation_handle, message_type_name, convert(xml,message_body) as MsgBody from ReceiverQ
--basic cleanup
USE master;
GO
DROP DATABASE SBTest;
GO
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment