High performance snapshotter #12
Labels
Priority 2: Should
High priority. Ideally, these issues are part of the release they’re assigned to.
Status: Resolved
Use to signal that work on this issue is done.
Type: Enhancement
Use to signal an issue enhances an already existing feature of the project.
Milestone
What are the limitations you encounter in the current version? Please provide a simple use-case.
Creating an aggregate snapshot requires the application to read events from the event store. Even though this is (possibly) a parallel process, reading from the event store distracts it from its main purpose: writing to it.
Please describe the enhancement you would like to have.
A high-performance snapshotter could maintain a weak hashmap with the known aggregate root instances as key and a copy of that aggregate as value. When an event comes in from a known aggregate, it applies that event to the copy. When a request for a snapshot comes in, it is able to produce a snapshot from the aggregate copy without a read operation on the event store or a lock on the original aggregate.
By maintaining a weak reference, an aggregate is removed automatically when all other references to it are removed. After all, an unreferenced aggregate will not generate any events.
Do you have any ideas on how to implement the enhancement? If so, any suggestions are welcome.
The 'RunningCopyAggregateSnapshotter' (name may change during implementation) could attach a listener to the repository's aggregate cache. When an element is put there that implements the Clonable interface, it can create a copy straight away. If that interface is not implemented, it must read the aggregate from the event store once.
An eviction of the aggregate from the cache may trigger (configuration option) a snapshot too.
The text was updated successfully, but these errors were encountered: