You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/events/projections/async-daemon.md
+45
Original file line number
Diff line number
Diff line change
@@ -483,3 +483,48 @@ using multi-tenancy through a database per tenant. On these spans will be these
483
483
484
484
There is also a counter metric called `marten.daemon.skipping` or `marten.[database name].daemon.skipping`
485
485
that just emits and update every time that Marten has to "skip" stale events.
486
+
487
+
## Querying for Non Stale Data
488
+
489
+
There are some potential benefits to running projections asynchronously, namely:
490
+
491
+
* Avoiding concurrent updates to aggregated documents so that the results are accurate, especially when the aggregation is "multi-stream"
492
+
* Putting the work of building aggregates into a background process so you don't take the performance "hit" of doing that work during requests from a client
493
+
494
+
All that being said, using asynchronous projections means you're going into the realm of [eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency), and sometimes
495
+
that's really inconvenient when your users or clients expect up to date information about the projected aggregate data.
496
+
497
+
Not to worry though, because Marten will allow you to "wait" for an asynchronous projection to catch up so that you
498
+
can query the latest information as all the events captured at the time of the query are processed through the asynchronous
if(!shards.Any())thrownewInvalidOperationException($"Cannot find any registered async projection shards for aggregate type {aggregationType.FullNameInCode()}");
0 commit comments