How to use a dialog retry timer for doing a web service call

Hi Remus,

I just started looking into SB about a week ago, so my question is likely to be pretty lame. However, that's not going to stop me from asking it :-)

We're trying to do something similar to what you're describing here. How do you "reset" a dialog timer Why would you need to deal with resetting timers (or with timers at all for that matter) in the event of a success Couldn't you rewrite the logic to be as follows

begin transaction
receive message
if message is web request
save state of request (http address, caller etc)
else if message is retry timer message
load state of request
endif
commit
do the web request (no transaction open)
if success
begin transaction
send back response
end conversation
commit
else
set a retry timer on the dialog (say 1 minute) using BEGIN DIALOG TIMER
endif

Also, when you set the retry timer you have to associate it with the saved request state, right Otherwise, how will the service know which request to load on receipt of the timer message

TIA.

Thank you for your reply! That helps explain some of it. May I have you comment on this scenario, below

Messages "A" and "B" are sent to a destination queue on a single dialog.

Message "A" is received from the queue.

Set a retry timer for 60 (e.g.) seconds. The retry time interval should be longer than the web request timeout, right

Do the web request for message A (e.g., hit a web service).

It fails.

Receive another message. It might be message "B", which has a lifecycle of its own. but we won't worry about message B for now. So let's instead assume we receive the conversation timer message.

Reload state for message A.

Set a retry timer for 60 seconds again.

Do the web request for message A again.

It succeeds this time. We send back the response, but we don't end the conversation b/c message B still needs to be processed. Instead we reset the timer and commit.

Message B is now received and processed (it arrived after the timer b/c it was stuck in traffic).

This scenario is pretty easy. But what about the case where B is received before the retry timer message If B succeeds, then it resets the timer (I'm looking at the logic right after the response is sent). Won't this kill the timer so that the timer set for A never gets called Aren't timers specific to dialogs I'm really confused trying to figure out dialogs, conversations, conversation groups, and the whole lot of it right now, but that's another topic in and of itself :-)

Another thing. What if both A and B fail, and what if they have different retry intervals You can't have 2 separate timers going, can you

In the meantime, I'll try to understand the examples on the link.

Thanks again for your help, Remus.

I'm trying to recycle dialogs on an account-by-account basis in a banking app. This is to benefit from dialog reuse (benefits discussed elsewhere) and to get the locking we desire (e.g., we want to minimize the chances of multiple threads hitting the same account at the same time). The app posts financial transactions from multiple channels (home banking, teller line, batch, etc). The app must communicate changes to account balances to other integration partners. So, when account A receives a payment, I need to let credit bureau XYZ know about it in "real time". Continuing with the example, I was trying to have the payment posting logic drop a message into a queue. Then the activated service(s) would send that message to all subscribers via web service calls (for example).

Am I making things too hard by trying to go about it this way