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
The normal, Marten workflow that happens in SaveChangesAsync() to append events captured by any permutation of IDocumentSession.Events.Append() is kinda heavyweight, and prone to concurrency violations if the same stream gets a lot of traffic. The pre-SaveChanges() workflow today is to:
Call into the database and "checkout" a number of event sequence values
For every stream being started or appended to, reach out to the database and get the current version number
Apply all the metadata to each pending event so that all of the event metadata is available to the Inline projections (that was a big request prior to the giant V4 release)
Great, makes the projections go, but it's also a little heavyweight in terms of performance because of the extra round trips going back and forth, and it's absolutely setting some subset of users up for concurrency issues when they're needing to rapidly append events to the same stream.
I'm proposing an alternative AppendQuick() or StartStreamQuick() alternative that purposely bypasses any of the current event pre-processing (and skips Inline projection usage most likely) as an explicit performance optimization. There's also the possibility of opting into this usage even for the normal Append()/StartStream() if there are no Inline projections. But I think I'd want to make that an "opt in" behavior.
This would be an absolute prerequisite for #2533 that's been on the back log forever.
The text was updated successfully, but these errors were encountered:
Docs on the quick append option
Few more tests for metadata on the new quick append mode.
More tests on the quick append
First end to end runs of the quick append mechanism
Roughed in QuickEventAppender and configuration logic for switching append modes
First successful pass at code generation for the quick append function
Lot more preparatory work for "quick append". Put back the old AppendEventFunction
Refactored on the code generation for append event operations in preparation for the quick append
Roughed in IncrementStreamVersionBy*** for later
The normal, Marten workflow that happens in
SaveChangesAsync()
to append events captured by any permutation ofIDocumentSession.Events.Append()
is kinda heavyweight, and prone to concurrency violations if the same stream gets a lot of traffic. The pre-SaveChanges() workflow today is to:Great, makes the projections go, but it's also a little heavyweight in terms of performance because of the extra round trips going back and forth, and it's absolutely setting some subset of users up for concurrency issues when they're needing to rapidly append events to the same stream.
I'm proposing an alternative
AppendQuick()
orStartStreamQuick()
alternative that purposely bypasses any of the current event pre-processing (and skips Inline projection usage most likely) as an explicit performance optimization. There's also the possibility of opting into this usage even for the normal Append()/StartStream() if there are no Inline projections. But I think I'd want to make that an "opt in" behavior.This would be an absolute prerequisite for #2533 that's been on the back log forever.
The text was updated successfully, but these errors were encountered: