MassTransit/MassTransit — pull request #53 by haf (2012-01-19 10:22:12+00:00)
Title: Eventstore + Sagas?

Hi guys,

This is a sort of discussion pull request, because I really need some discussion with you guys before I continue down this path.

First of all, read the commit message and look at EventStoreIntegration.Tests/Saga_Tests.cs. Then, have a look at the spec and the rest of it. It's quite messy right now, but at least it should compile and work out of the box, and the tests shouldn't hang.

Questions:

* The filters of `ISagaRepository` - are they used inside of the state machine?
* These filters - are they related to the life cycle of the saga? I don't have a clear conceptual picture in my mind of how the sagas in MT work - is it possible to have S1 { CorrId = 1, Tag = A }, S2 { CorrId = 1, Tag = B }? Is this when where the filtering conditions come into play?
* As of now, there's no deletion - don't we need that? I'm uncertain on how MT loads the list of sagas - by correlation id I presume - but what about the above question? A stream has its streamid uniquely identified by this id, essentially making it a key-value store and allowing it to map event sourcing to these types of underlying data stores.
* In order to integrate and make the second test pass, I need a way to hook into the saga state machine. The idea is that the *state deltas* (the events of the event store) in this pull request make up the saga state, rather than having it as snapshots, allowing e.g. saga merging after-the-fact if we for example write to a DHT, like Rhino ESB does when it want high-availability writes (with potential conflicts) - the difference here would be that we could merge with events as well.
* How do we handle mutual exclusion in a distributed system of multiple saga buses with same saga types running?

Summary: some progress, but what about filtering? Next stop is to get a handle into the sagas as well.

Observations:

* log4net's versions is a problem. How event-store has solved it is really nice - I suggest a similar log factory and then log4net would be an integration point rather than direct dep.
* We'd need to refactor the saga tests to avoid Thread.Sleep statements - even if we're doing "integration". E.g. by using an in-memory sql database like Rhino.Security does - this would support the optimistic concurrency concepts we need.