Conversation that dont end.

Hi There

Message ordering is of utmost importance in our application.

As i found in testing the only way to ensure message ordering is if they are in the same conversation.If you send multiple messages in different conversations there is no garantee which will be processed first.

Therefore i will be creating conversations that last "forever", that is using a single conversation.

I plan on doing a BEGIN DIALOG CONVERSATION when an inititator site is setup and writing the conversation handle guid to a table.

I will them simply SEND ON SONVERSATION using the guid, i will never issue a end conversation from target or initiator.

Is this theory solid, ie: is there a better way or best practice to do this?

I know that conversatons persist with sql server restarts, however what happens if an initiator site db is restored ?

I was thinking of adding logic to first check if a conversation endpoint exists with the specified guid if not , then start another conversation. But is this the best way?

Thanx

If you need ordering, you must use a single conversation (dialog) to send your messages over. You must be aware however, that imposing this requirement means that messages can only be processed serially and you will not have the benefits of parallel processing and scaling out.

Conversations are durable, so they will persist restarting the engine, detaching/attaching the database, etc. However, if you take a backup, let the conversation continue (i.e. more messages are exchanged) and then restore the database, the endpoint's last sent message sequence number will be decreased. If you were to send a message from that endpoint now, it will be assigned a lower message sequence number. The remote endpoint will not ack this message sequence number since it is lower than the one it already has acked and hence the conversation will not be able to continue. At this point, the only option is to error or end the dialog (manually) and start all over.

|||

HI Rushi

Yes i have already factored in the fact that no serial processing can occur.

But as far as the rest goes is the thoery ok, i mean starting a dialog when an inititator is setup and storing and using the conevrsation guid for the life of the conversation.

If the DB is restored and tlogs replayed to the latest point in time messaging should be ok? I also have a transaction audit i mirror at initiator and target so if a restore happens i can set the initiator in sequence. Or like you said worst case scenario end and restart the dialog.

Just want to make sure there is not something else vital i am overseeing when using persistant dialogs.

Thank You for the feedback.