Ending a Conversation

I am attempting to learn Service Broker from Bob Beauchemin's book "A Developer's Guide to SQL Server" - Chapter 11. I'm finding it to be very good but I'm confused over the concept of closing a conversation. Could someone answer the following questions for me?

When a conversation is ended, can the conversation handle that was created when the conversation was created still be used? (I assume not)

Beauchemin says, on page 511, that when a conversation ends, "Any messages still in the queue from the other end of the conversation are deleted with no warning." Does this mean that if I send a message that expects a reply, but I end the conversation, the message is still sent, it is still received by the other endpoint, the other endpoint processes it, but I'll never receive the reply?

Beauchemin says that if no lifetime is specified, the conversation is active for the number of seconds which can be represented by the maximum size of an integer. Does this mean that if I don't specify a lifetime, a conversation is active for many, many years?

Thanks very much.

Amos

I find Bob's book a real treasure chest, covering so much of the new SQL features.

Amos wrote:

1. When a conversation is ended, can the conversation handle that was created when the conversation was created still be used? (I assume not)

Yes and no. After ending a conversation the handle can no longer be used to SEND (or MOVE), but it can still be used to END again (a no-op) or to END ... WITH CLEANUP (e.g. in case messages are stuck in transmission_queue and you know the're never going to get trough). Both sites have to END the conversation and once the EndDialog message is received from the other side, the conversation endpoint handle is deleted so all verbs (SEND,END, MOVE) will fail because the conversation handle value is invalid. the target side might keep around a handle for up to 30 minutes after it was closed (ENDed by both sides) for security reasons (prevent a replay attack).

Amos wrote:

2. Beauchemin says, on page 511, that when a conversation ends, "Any messages still in the queue from the other end of the conversation are deleted with no warning." Does this mean that if I send a message that expects a reply, but I end the conversation, the message is still sent, it is still received by the other endpoint, the other endpoint processes it, but I'll never receive the reply?

Yes, you'll not receive any reply, since you already declared that you're no longer interested in the result of this conversation (by ENDing it). Even worse, if the conversation is ended with an error, you'll never know that about error, including system errors like 'SEND permission denied'. See http://blogs.msdn.com/remusrusanu/archive/2006/04/06/570578.aspx for more on this.

Amos wrote:

3. Beauchemin says that if no lifetime is specified, the conversation is active for the number of seconds which can be represented by the maximum size of an integer. Does this mean that if I don't specify a lifetime, a conversation is active for many, many years?

That is correct. In theory, your conversation will expire after many, many years (68, I believe). In practice, I doubt any application written today will be around after 60 years...

HTH,
~ Remus

Encryption Best-Practices

Please forgive me if I have overlooked a thread that answers this question, but I assure you that I have looked.

I would really appreciate a guide of sorts that would tell me the correct steps to take to properly secure a column in my database. I don't need specifics on how to do each step, I either have those already or can find them myself. In fact, I have already successfully encrypted and decrypted some data. I just want to make sure that I create the right keys and certificates and that I follow best-practices as far as backups and stuff is concerned.

Thanks,

Todd Sparks

Here are some suggestions:

- if you will need to share the same encryption key across databases or servers, make sure that you create the key using the KEY_SOURCE and IDENTITY_VALUE parameters.

- if you protect a key using a password, pay special attention to how the password is manipulated by your application and make sure it doesn't leak out. Do not hardcode passwords in your application - have the user enter them instead.

- use strong encryption algorithms. We recommend AES if you only work with Windows 2003. If you need to decrypt on other OS's, then use TripleDES. Avoid RC4.

- open the encryption keys when you need to use them and close them after you are done using them.

Thanks
Laurentiu