EventCountSnapshotTriggerDefinitionprovides the mechanism to trigger snapshot creation when the number of events needed to load an aggregate exceeds a certain threshold. If the number of events needed to load an aggregate exceeds a certain configurable threshold, the trigger tells a
Snapshotterto create a snapshot for the aggregate.
Snapshottersets the actual snapshotter instance, responsible for creating and storing the actual snapshot event;
Triggersets the threshold at which to trigger snapshot creation;
Snapshotteris responsible for the actual creation of a snapshot. Typically, snapshotting is a process that should disturb the operational processes as little as possible. Therefore, it is recommended to run the snapshotter in a different thread. The
Snapshotterinterface declares a single method:
scheduleSnapshot(), which takes the aggregate's type and identifier as parameters.
AggregateSnapshotter, which creates and stores
AggregateSnapshotinstances. This is a special type of snapshot, since it contains the actual aggregate instance within it. The repositories provided by Axon are aware of this type of snapshot, and will extract the aggregate from it, instead of instantiating a new one. All events loaded after the snapshot events are streamed to the extracted aggregate instance.
Serializing a Snapshot EventDo make sure the
Serializerinstance you use (which defaults to the
XStreamSerializer) is capable of serializing your aggregate. The
XStreamSerializerrequires you to use either a Hotspot JVM, or your aggregate must either have an accessible default constructor or implement the
AbstractSnapshotterprovides a basic set of properties that allow you to tweak the way snapshots are created:
EventStoresets the event store, which is used to load past events and store the snapshots. This event store must implement the
Executorsets the executor, such as a
ThreadPoolExecutorthat will provide the thread to process actual snapshot creation. By default, snapshots are created in the thread that calls the
scheduleSnapshot()method, which is generally not recommended for production.
AggregateSnapshotterprovides one more property:
AggregateFactoriesis the property that allows you to set the factories that will create instances of your aggregates. Configuring multiple aggregate factories allows you to use a single
Snapshotterto create snapshots for a variety of aggregate types. The
EventSourcingRepositoryimplementations and the
AggregateConfigurationprovide access to the
AggregateFactorybeing used for a given Aggregate. Both provide the factory through the
AggregateConfiguration#aggregateFactorymethods respectively. The result from either can be used to configure the same aggregate factories in the
Snapshotteras the ones used by the Aggregate.
Snapshotter ConfigurationIf you use an executor that executes snapshot creation in another thread, make sure you configure the correct transaction management for your underlying event store, if necessary.For both non-Spring and Spring users a default
Snapshotteris provided. The former uses the Configuration API to provide a default
AggregateSnapshotter, retrieving the aggregate factories from the registered Aggregates /
AggregateConfigurations. Spring uses a
SpringAggregateSnapshotter, which will automatically looks up the right
AggregateFactoryinstances from the application context when a snapshot needs to be created.The
@Revisionannotation has a dedicated, automatically configured
SnapshotFilterimplementation. This implementation is used to filter out non-matching snapshots from the
Repository's loading process. So when the
@Revisionannotation is used on an aggregate the snapshots will be filtered out automatically. When the
@Revisionon an aggregate is missing a
RevisionSnapshotFilteris configured for revision
SnapshotTriggerDefinitionfor an aggregate as a Spring bean. In order to tie the
SnapshotTriggerDefinitionbean to an aggregate, use the
@Aggregateannotation. Listing below shows how to define a custom
EventCountSnapshotTriggerDefinitionwhich will take a snapshot every 500 events.
Snapshotterinstance, if not explicitly defined as a bean already, will be automatically configured for you. This means you can simply pass the
Snapshotteras a parameter to your
Snapshots as a replacement of your events?Normally, you can archive all events once they are part of a snapshot event. Snapshotted events will never be read in again by the event store in regular operational scenarios. However, if you want to be able to reconstruct an aggregate state prior to the moment the snapshot was created, you must keep the events up to that date.
AggregateSnapshot, which stores an entire aggregate as a snapshot. The motivation is simple: your aggregate should only contain the state relevant to take business decisions. This is exactly the information you want captured in a snapshot. All event sourcing repositories provided by Axon recognize the
AggregateSnapshot, and will extract the aggregate from it. Beware that using this snapshot event requires that the event serialization mechanism needs to be able to serialize the aggregate.
AggregateSnapshotevent would it be smart to no longer load these.
SnapshotFiltercan be defined per Aggregate type or for the entire
SnapshotFilteris a functional interface, providing two main operations:
combine(SnapshotFilter). The former provides the
DomainEventDatawhich reflects the snapshot events. The latter allows combining several
SnapshotFilterfor an aggregate as a Spring bean. In order to tie the
SnapshotFilterbean to an aggregate, use the
@EventHandler), you can annotate a method that initializes full aggregate state based on a snapshot event. The code sample below shows how snapshot events are treated like any other domain event within the aggregate.
AggregateSnapshot. This type of snapshot event contains the actual aggregate. The aggregate factory recognizes this type of event and extracts the aggregate from the snapshot. Then, all other events are re-applied to the extracted snapshot. That means aggregates never need to be able to deal with
Cacheobject. The framework currently provides several implementations to choose from:
WeakReferenceCache- An in-memory cache solution. In most scenarios, this is a good start.
AbstractCacheAdapter- Abstract implementation towards supporting Axon's
CacheAPI. Helpful in writing an adapter for a cache implementation that Axon does not support out of the box.
Cache, please consider the following guidelines. They will help you get the most out of your caching solution:
RollbackConfigurationon your command bus. By default, the configuration will roll back the unit of work on unchecked exceptions for command handlers and on all exceptions for event handlers.
Aggregateannotation allows specification of the cache bean: