title: NServiceBus Saga handle a message-type multiple times gives concurrency exception
body: <p>We have a NServiceBus implementation that handles multiple message-types:</p>
  
  <pre><code>public class StateCoordinator : Saga&lt;MessageData&gt;, 
                                  IAmStartedByMessages&lt;CreateMessage&gt;, 
                                  IAmStartedByMessages&lt;ConfirmMessage&gt;
  </code></pre>
  
  <p>MessageData is something like this:</p>
  
  <pre><code>public class FlowData : IContainSagaData
  {
      [Unique]
      public Guid MappingId { get; set; }
  
      public Guid Id { get; set; }
  
      public string OriginalMessageId { get; set; }
  
      public string Originator { get; set; }
  
      public List&lt;MessagePart&gt; MessageParts { get; set; }
  }
  
  public MessagePart
  {
      public int Id { get; set; }
  
      public string Status { get; set; }
  }
  </code></pre>
  
  <p>The CreateMessage has a MessagePart that is added to MessageParts in its handler. The ConfirmMessage updates the status of a particular MessagePart.</p>
  
  <p>This is the scenario:</p>
  
  <p>1) A first CreateMessage is received. This creates the Saga in Raven and adds a MessagePart (with status "1") to MessageParts.</p>
  
  <p>2) A first ConfirmMessage is received. This updates the Status of the first added MessagePart in the Saga to "1 2". This is vissible in the browser when going to the document in RavenDB.</p>
  
  <p>3) A second CreateMessage is received. This adds a second MessagePart to MessageParts. When looking to the Data, the status of the first MessagePart is still "1" and not "1 2" and this throws a concurrency-exception (the ActualETag does not equals the ExpectedETag):</p>
  
  <pre><code>A first chance exception of type 'Raven.Abstractions.Exceptions.ConcurrencyException' occurred in Raven.Client.Lightweight
  
  Additional information: PUT attempted on document 'flow/79a7ee20-f090-4648-9b62-a3da00d87c93' using a non current etag
  </code></pre>
  
  <p>It looks like the Saga-data is cached per message-type. Is this so? Is there a solution?</p>
  
  <p>NOTE:</p>
  
  <p>We are using multiple IAmStartedByMessages but when the ConfirmMessage is before the CreateMessage, then this message is added to a queue until the CreateMessage is handled.</p>