Understanding the transactional behavior of an Azure Message Queue
November 5, 2010 Leave a comment
One of the main differences is how they behave transactionally. Well in fact the remote queueing systems aren’t transactional at all, but support a timeout mechanism to simulate transactions (often called queue-peek-lock mechanism).
The queue-peek-lock mechanism works in the following way:
- Once a message is picked up by a process, the message will stay in the queue but will become invisible to other processes.
- When the process is finished handling the message, it has to explicitly remove the message from the queue.
- If the process fails to do so in a certain timeframe, because it crashed or isn’t done yet, the message will reappear on the queue.
- And the message will be picked up by another process, executing the same logic again.
But hold on a minute! In your previous article you’re setting IsTransactional to true and now your telling me there are no real transactions, what’s up with that? Well, indeed, setting transactional to true means that we will play nicely along in this queue-peek-lock mechanism, setting it to false means we will immediately delete the message after receiving.
To avoid frequent occurrence of multi-processing you must ensure that your message handler completes before the timeout expires. By default the timeout is set to 30 seconds, but you can control it yourself using the MessageInvisibleTime property on the AzureQueueConfig configuration section (expressed in milliseconds).
But no matter what value you assign, multi-processing is always a potential problem on remote queueing systems, so make sure that your message handlers have been implemented in an idempotent way. In the future I hope to figure out a generic solution to this problem and add it to NServiceBus, but today I have no clue how to do it. I know Ayende divised the following solution using local transaction, but as azure table storage doesn’t support this kind of transactions it’s not really suitable in our case.
If you have any suggestion in this matter, I would, ofcourse, be happy to hear them…