Jonathan Oliver

I have just released v2.0 of my CQRS EventStore project. I have been amazed at and delighted by the number of contributors the project. Interest continues to grow and implementations for various storage engines continues as well as other serialization strategies. Download Download the .NET 4.0 release here: https://github.com/downloads/joliver/EventStore/EventStore-2.0.11157.39-net40.zip Download the .NET 3.5 release here: https://github.com/downloads/joliver/EventStore/EventStore-2.0.11157.39-net35.zip The Roadmap First and foremost, any volunteers to help me with the NuGet package? Ideally we'd have one package per storage engine that contains . »

Let's rewind several years. At the time I was struggling through a large project with ever increasing complexity in my "domain model" (if you could really call it that) along with an explosion of dependencies—from NHibernate (including Fluent NHibernate, NHibernate.LINQ), log4net, unit tests, and web services all over the place. It was crazy—crazy big, crazy hard to debug, and crazy hard to figure out what was happening through the rats nest of dependencies. »

Note to self (and to anyone else who cares): If IIS7 is giving back 404 pages and it's pointing to the proper directory and configured with Integrated Mode, and the MVC routes appear to be correct, it might be that there are no controllers registered with the container. This one bit me a little bit today--I kept getting 404 pages from IIS and everything appeared to be configured correctly. Finally, when I registered the controller with the container the 404's went away and I was able to continue. »

I was working with some legacy data the other day when all of a sudden I realized that I needed to know exactly how old the data was. The problem? I had no way to get that information precisely. The specific scenario was I was working with phone numbers and addresses of customers. Knowing how old a piece of information—especially contact info—is critical because the older or more stale it is, the higher the potential for error. »

One of the tricks to message-based solutions is handling messages that come out of order. In some instances the application code must be made resilient to this situation. In other cases, it can be easier to re-sequence the messages and then apply each messages in sequence. In one of my current systems this is the route we took—re-sequencing messages if they arrive out of order. One of the easier possibilities is to have the read model poll the event store for new commits. »

In my last blog post I ranted about two-phase commit (2PC) and MSDTC. This is going to be a quick post about a few techniques that I use. The basic premise is that I break a two-phase commit apart into multiple transactions such that each is handled independently but with resiliency against failure scenarios. There are a number of different methods and patterns that can be used to avoid 2PC and each method is different depending upon the application-level requirements. »

I'm just not a fan of the Microsoft Distributed Transaction Coordinator. I've tweeted and blogged a few times about it, but I've never really gone into why. I should preface my remarks by saying that MSDTC does work—it will facilitate and coordinate distributed transactions using a two-phase commit (2PC) protocol. I should also say also that much of what follows is a rant against 2PC and MSDTC is a casualty in the argument. »

Just remember that when two assemblies have internalized a reference to another assembly using ILMerge, each gets their own "copy" of static variables. That is to say, that the class MyClass1.SomeStaticInstance is no longer the same between the two assemblies. I was kicking against this one for the better part of an hour. At first I thought it was some quirk with the [ThreadStatic] attribute I was using. It wasn't. »

I received the following email today and I thought I'd answer it as a blog post so that all can benefit: If you remove the 2PC from the system, how do you deal with ensuring that published events are: * truly published, * not lost, * that there is confidence that the interested parties (subscribers) are truly receiving and processing the events in a 'timely' manner * and that there is confidence and a method that the system can gracefully recover from unexpected situations? »

There are a number of interesting and unique advantages offered by event sourcing as well as messaging in general. Some of these advantages include the ability to perform merge-based, business-level concurrency—as compared to simple optimistic or pessimistic concurrency. Further, the ability to replay all stored messages into new or alternate models because business context and intent has been captured, is invaluable. One interesting advantage that may not seem like much at first is the immutability of the events once they are committed to a persistent medium. »