Что заставляет EventStore так легко вызывать ConcurrencyException? - PullRequest
Новая
       36

Что заставляет EventStore так легко вызывать ConcurrencyException?

3 голосов
/ 18 марта 2012

Использование JOliver EventStore 3.0 и только начало работы с простыми примерами.

У меня есть простая реализация pub / sub CQRS с использованием NServiceBus. Клиент отправляет команды на шину, сервер домена получает и обрабатывает команды и сохраняет события в хранилище событий, которые затем публикуются на шине диспетчером хранилища событий. сервер модели чтения затем подписывается на эти события, чтобы обновить модель чтения. Ничего особенного, в общем-то, по книге.

Это работает, но только в простых тестах я получаю множество исключений параллелизма (периодически) на сервере домена, когда событие сохраняется в EventStore. Он правильно повторяет попытку, но иногда достигает 5-кратного предела, и команда попадает в очередь ошибок.

С чего бы мне начать расследование, чтобы выяснить, что вызывает исключение параллелизма? Я удаляю диспетчер и просто сосредотачиваюсь на хранении событий, и у него та же проблема.

Я использую RavenDB для сохранения моего EventStore. Я не делаю ничего необычного, только это: 

using (var stream = eventStore.OpenStream(entityId, 0, int.MaxValue))
{
  stream.Add(new EventMessage { Body = myEvent });
  stream.CommitChanges(Guid.NewGuid());
}

Трассировка стека для исключения выглядит следующим образом:

2012-03-17 18: 34: 01,166 [Работник.14] ПРЕДУПРЕЖДЕНИЕ NServiceBus.Unicast.UnicastBus [(null)] <(null)> - EmployeeCommandHandler не удалось обработать сообщение. EventStore.ConcurrencyException: исключение типа Событие EventStore.ConcurrencyException было сгенерировано. в EventStore.OptimisticPipelineHook.PreCommit (Попытка фиксации) в C: \ Code \ Public \ EventStore \ SRC \ проектируемый \ EventStore.Core \ OptimisticPipelineHook.cs: линия 55 в EventStore.OptimisticEventStore.Commit (попытка фиксации) в C: \ Code \ Public \ EventStore \ SRC \ проектируемый \ EventStore.Core \ OptimisticEventStore.cs: линия 90 в EventStore.OptimisticEventStream.PersistChanges (Guid commitId) в C: \ Code \ Public \ EventStore \ SRC \ проектируемый \ EventStore.Core \ OptimisticEventStream.cs: линия 168 в EventStore.OptimisticEventStream.CommitChanges (Guid commitId) в C: \ Code \ Public \ EventStore \ SRC \ проектируемый \ EventStore.Core \ OptimisticEventStream.cs: линия 149 в CQRSTest3.Domain.Extensions.StoreEvent (IStoreEvents EventStore, Guid entityId, Object evt) в C: \ dev \ test \ CQRSTest3 \ CQRSTest3.Domain \ Extensions.cs: строка 13 в CQRSTest3.Domain.ComandHandlers.EmployeeCommandHandler.Handle (ChangeEmployeeSalary сообщение) в C: \ DEV \ тест \ CQRSTest3 \ CQRSTest3.Domain \ ComandHandlers \ Emplo yeeCommandHandler.cs: строка 55

1 Ответ

10 голосов
/ 19 марта 2012

Я понял это.Пришлось копаться в исходном коде, чтобы найти его, хотя.Я хотел бы, чтобы это было лучше задокументировано!Вот мое новое соединение с хранилищем событий: 

EventStore = Wireup.Init()
          .UsingRavenPersistence("RavenDB")
          .ConsistentQueries()
          .InitializeStorageEngine()
          .Build();

Мне пришлось добавить .ConsistentQueries (), чтобы поставщик постоянства воронов внутренне использовал WaitForNonStaleResults, когда хранилище событий запросов превращалось в ворон.

В основномкогда я добавляю новое событие, а затем пытаюсь добавить еще одно, прежде чем raven догонит индексирование, ревизия потока не обновлялась.Второе событие наступит на первое.

...