This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Reliable Messaging, Transactions, and Messages â" take 2
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
"I would go even further and say that all messages need to be reliable. Even a missed stock update can result in lost money if the update brought the stock value above or below a threshold for a buy/sell order. I cannot think of any application I've written where a message was sent that I said, "it doesn't really matter if it gets there." Because if that were the case, why send it?"
I wouldn't go that far. The point is not whether or not it matters if the message gets to its destination. The point is that different kinds of data have different volatilities - the amount of time the data is valid for is different for a command sent by a user and for a stock update that is published 6 times a minute. While we may not want to ever lose the user's command (buy, sell, or whatever), if the network isn't able to transfer a stock update for over 10 seconds, it might as well throw it away since the new update that was just published is now that valid one. Again, we're talking about failure cases here - not the common case.
So, for each message type we can/need to decide how volatile the data is that the given message type will carry, and based on that define the recoverability interval - 10 seconds in the above example. If we were to define this in code, we might use an attribute that looked like this:
[Recoverable(Timeout=TimeSpan.FromSeconds(10))]
On to transactions. Bruno states:
"Breaking it down further, at the basic level, one could say that are two types of messages: transacted or not."
I agree, but I'd say that the transactional behavior is already defined by the recoverability description. A recoverable message should be handled within a transaction, as I said in the previous post - a transaction that wraps the pulling of the message from the queue, any database changes, and the sending of other messages. Non-recoverable messages don't need this level of transactional behavior. Although they may well involve transactional business logic against the database, as in Bruno's example, sell when the stock reaches a certain threshold, the failure cases that we deal with put a new spin on it.
If the server that is currently handling the message restarts for some reason, what should happen? If you take into account that a restart can take upwards of 15 seconds, if you go to handle that same message again, you may well be getting yourself into trouble since "the rest of the world" has already moved on. You may not want to sell if you find out that after the restart the previous stock price is no longer true.
So, at the service level, all you need to deal with is recoverability - it'll define service-level transactional behavior. Internal transactions are orthogonal and deal more in the actual data in the message (the stock quote itself) rather than the message type.
Previous Topic
