Jonathan Oliver

In several of my previous posts I discussed how to avoid the overhead of a two-phase commit while still being able to maintain an application-level transactional consistency between two resources, such as a message queue and durable data store, e.g. a database. When considering how to implement idempotency there are a number of factors to consider. Let us examine each of these in turn. First, is the message inherently idempotent? That is, does it contain and operation that contains a fixed value at a point in time such as a stock quote rather than a transformational instruction such as " »

When using non-transactional queues processing a message is trivially easy—just handle the message and write to your data store. If the process dies and we lose a message, that's okay. But when using a transactional queue things can become more difficult because we want our infrastructure to ensure consistency between our message queues and application database. I have already outlined the trouble of using two-phase commits in a previous post. »

In the industry there is a general trend away from locking, two-phase commits. In theory, quorum and Paxos-style commits ensure consistency across disparate resources, but why not avoid the issue altogether? The fundamental idea behind each of these commit protocols is to ensure application consistency at an infrastructure level. Rather than relying on low-level protocols to ensure consistency, why not embrace inconsistency and handle it explicitly within our application? In this way we can avoid anything but simple, " »

When handling messages in NServiceBus it may become necessary to consume the same message multiple times but in different ways. For example, suppose you wanted to update separate yet related tables in the database. You could throw all of the business logic into a single message handler and be done with it. The only problem is that this message handler would be performing multiple actions and the intention behind the handler would be obscured. »

NServiceBus is great. That's really all there is to it. The framework is incredibly flexible such that it can be extended without too much effort. But there are a few small points of friction that we've encountered. This article shows how we've been able to address one such point. Choose Your IoC Container Because NServiceBus allows us to choose an IoC container rather than forcing us to use a predefined one, we gain a lot of flexibility. »

NServiceBus message modules are global objects that are invoked at various stages of processing for a physical message, e.g. during receipt, when processing is complete, and upon any error condition. Their typical use case is to setup thread-specific values, such as outbound message headers or starting up a new instance of ISession and storing it on the thread. Message modules, while incredibly powerful, are somewhat troublesome. First, because they're shared, we have to remember to to avoid storing any state about message processing unless we store it on the thread by decorating it with the ThreadStatic attribute. »

I recorded my CQRS presentation that I gave at the Utah Code Camp today (Saturday). The video is divided in two parts in order be under the size limit imposed by the video hosting provider. If it says "Video not available", try back in a few minutes, I just uploaded the videos and they're in the process being converted. Converted to what, I don't know, CQRS perhaps, but converted nonetheless. »

I will be giving a presentation on CQRS at the local code camp this Saturday, March 27 at about 3:00 PM. Here's the schedule: http://utahcodecamp.com/Web/Schedule If you are unable to attend, I will be recording the presentation and posting the video and slides online. »

One of the great things about CQRS is that, because all read responsibilities have been removed from the service layer, the mechanism for storage can be vastly different. We can continue to use a relational database but we also have the option to utilize alternative storage engines, such a document database or an object database. From an application layer perspective, when we employ CQRS and utilize the event sourcing pattern we only require lookups based upon a unique key. »

Greg recently posted on the benefits of using event sourcing instead of traditional state-based persistence mechanisms. It's a great article and definitely worth reading multiple times. But there was one paragraph in particular that caught my attention that gave me one of those great ah-ha moments. One of those benefits is that we can avoid having to use a 2pc [two-phase commit] transaction between the data model and the message queue (if we are using one)… the reason for this is that the event storage itself is also a queue, we could be trailing the event storage to place the items on the queue (or directly use the event storage as a queue). »