search

NEventStore / NEventStore.Persistence.RavenDB

RavenDB Persistence Engine for NEventStore
MIT License
2 stars 10 forks source link

Issues with RavenDB persistence #3

Closed damianh closed 9 years ago

damianh commented 10 years ago

(Moved from https://github.com/NEventStore/NEventStore/issues/110 , go there to see the rest of the thread)

Hi Jonathan,

We have uncovered recently a few issues when persisting events into RavenDB which are all related to how indexes work there. It would be nice to hear what you think about these:

By default RavenPersistenceEngine is constructed with ConsistentQueries option set to "false" which opens a time window when it is possible to create & save an aggregate, but then fail to load it back upon receiving next message delivering new update. That is because Raven was under pressure and couldn't update "RavenCommitsBy.." index fast enough. If we enable ConsistentQueries then under heavy pressure we get Raven's timeout exceptions (Waited for 16,493ms for the query to return non stale result). It passes fine on second retry, since index is updated. EventStore defines several "RavenCommitsBy... and "RavenSnapshot..." indexes per database, but they are all global (non AR or Saga specific) and if you have several aggregates/sagas who save into this EventStore -> staleness of these indexes is defined by new events coming to ANY of those, instead of being AR or Sage bound. Do you also see benefit of maintaining index per AR/Saga type? Thanks, Anton.

kblooie commented 9 years ago

This will be a non-issue when we refactor to not use queries. #11 will track that progress