Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High performance snapshotter #12

Closed
abuijze opened this issue Dec 3, 2011 · 0 comments
Closed

High performance snapshotter #12

abuijze opened this issue Dec 3, 2011 · 0 comments
Assignees
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

Comments

@abuijze
Copy link
Member

abuijze commented Dec 3, 2011

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.

@abuijze abuijze closed this as completed Dec 30, 2016
@smcvb smcvb added 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. labels Jul 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

2 participants