This requires the following setup:
@EnableCaching
annotationorg.axonframework.common.caching.Cache
bean- we use an implementation of type
org.axonframework.common.caching.EhCacheAdapter
. This requires:net.sf.ehcache:ehcache
dependency (EhCache v2)ehcache.xml
- we use an implementation of type
@Aggregate(cache = "axonCache")
withaxonCache
the name of theorg.axonframework.common.caching.Cache
beanSpringAggregateLookup.postProcessBeanFactory()
uses this to configure theBeanDefinition
used to instantiateCachingEventSourcingRepository
ExampleIT
demonstrates that:
- caching aggregates may result in stale aggregates when writes are done by multiple nodes (
SimpleCommandBus
)- aggregates may reject valid commands (
testStaleAggregateRefusesValidCommand()
) - aggregates may accept invalid commands and publish events, that are in turn rejected by axon
server (
testAxonServerRefusesEventFromStaleAggregate()
)
- aggregates may reject valid commands (
- caching aggregates never results in stale aggregates when using the single writer principle (
AxonServerCommandBus
= default command bus when using axon server), as demonstrated bytestNoStaleAggregatesWithAxonServerCommandBus()
. Axon reference states that:https://docs.axoniq.io/reference-guide/v/4.5/axon-server-introduction#message-patternsCommands are always sent to exactly one application. Commands for the same aggregate are always sent to the same application instance, to avoid problems with concurrent updates of the aggregate.