I paid my "Windows tithing" recently and did a complete reinstall. Fortunately Windows is now a guest VM inside of a Linux host. A settings change I had made a long time ago but forgot to reapply during my reinstall was for IIS. Whenever I was developing--even locally--I would get "500" errors from IIS which would then display a generic and very unhelpful error page. The solution is to go into IIS and disable generic error messages: »
NServiceBus is an "Any CPU" framework. It doesn't have an 32-bit or 64-bit specific code. This makes it very easy to transition between 32-bit and 64-bit operating systems. Unfortunately, not all assemblies are or even can be compiled using the default "Any CPU" architecture. In many, if not most cases, this is related to legacy systems that have 32-bit specific code for platform interop with native C libraries, etc. If you use the default host--NServiceBus. »
There have been quite a few posts related to issues installing the VirtualBox Extension Pack for both Windows and Linux hosts. http://forums.virtualbox.org/viewtopic.php?p=11262&sid;=334fb962995ae00d32bb8988192f701chttp://www.virtualbox.org/ticket/7899http://www.virtualbox.org/ticket/7972http://blogs.oracle.com/wim/2010/12/oracle_vm_virtualbox_40_extens.htmlThe error message given is very cryptic: "Failed to install the Extension Pack" NS_ERROR_FAILURE (0x80004005) Weird. In digging through the above posts I found tidbits of the solution that I was able to put together. I'm currently running a Ubuntu 10.10 x64, so here's how I solved the problem and installed the extension pack. »
For the latest episode of the Distributed Podcast, we looked a little more closely at my CQRS EventStore project. If you've wanted to get some background and understanding on where, when, and why to use the library, now would be a good time. »
I just came across a really cool library that facilitates in-memory messaging—very similar to the way this is handled in Scala and Erlang using the Actor model. It's called retlang. Check it out. »
I will be speaking at two upcoming conferences. The Rocky Mountain Tech Trifecta in Denver, Colorado on March 5th and the Utah Code Camp in Salt Lake City, Utah on March 19th. I will be speaking on distributed systems and messaging. I'll be touching on the following topics: The Fallacies of Distributed Computing Messaging Publish/subscribe NoSQL CAP CQRS Event sourcing (depending upon time constraints) If you're attending the Utah Code Camp, go vote for my session. »
I've got to hand it to the NoSQL teams. In some recent work on my EventStore project, I have seen how, when you give them a value to story and then query the associated document/row/whatever, the NoSQL solutions hand back the *exact same value* every single time. The RDBMS crowd is another story. MySQL has an outstanding bug whereby it truncates any DateTime values and forgets the milliseconds on the value. »
One of the fundamental advantages of event sourcing coupled with CQRS is the ability to quickly and easily build your read models from your event stream. This includes the ability to build alternate views or projections from your data (which is a *huge* advantage) as well as the ability to scale by creating duplicate, load-balanced read models from your event stream. In order to scale your reads using something other than JSON files hosted on a CDN, such as a RavenDB, CouchDB, or even a traditional RDBMS, we need the ability to get all events from the event store. »
There is an interesting thread on the DDD/CQRS group involving sagas. I'm posting my reply below because I want to make it available as a solution to those that encounter this same problem. All replies should be directed on the CQRS thread instead of replying here below. To give a small amount of background, the question is related to how a failure or refusal on the part of the domain to perform some action is communicated back to the saga such that it can take the appropriate, compensating action. »
As outlined in the architectural overview document, the central model in version 2.0 of the EventStore is that of a "commit" consisting of a series of events. By focusing on a commit we are able to liberate ourselves from the high requirements introduced when using a two-phase commit protocol. At the same time, by reordering slightly the sequence of operations when performing a commit to the configured persistence engine, the EventStore is able to avoid using transactions at all and yet still maintain transactional integrity, all of which has been outlined in the architectural overview document. »