Hello,
Am I correct in understanding that the DisruptorCommandBus only uses the passed in cache to invalidate it and that it is the responsibility of the EventStore to make active use (check and put) of whatever cache is in place?
JAmes
Hi James,
that’s not entirely correct. The DisruptorCommandBus is also a factory for Repositories. These repositoties use the cache to store aggregates. They will also invalidate cache entries when a Unit of Work is rolled back (as the in-memory state no longer reflects the actual state).
The DisruptorCommandBus also uses a small internal cache, based on Weak References, which is purely meant to prevent concurrency problems. Because of this internal cache, the Cache instance you configure might not get a read hit for each time you load an aggregate.
The Event Store doesn’t need to do anything special for the DCB. Just return some events on request and append as fast as it can…
Cheers,
Allard
Hey Allard,
It looks like the DCB Repository delegates its work to the CommandHandlerInvoker DisruptorRepository.
I can see in CHI.DR.load() that it checks the WeakHashMap (firstLevelCache), but failing that it looks like it hits the EventStore directly.
I don’t see where it actually uses the jsr107 cache?
JAmes
Hi James,
you’re right. I am afraid old age is starting to kick in. I was absolutely convinced that I implemented caching. But there isn’t any entry being stored in the cache.
Thanks for noting this before the 2.0 release 
Cheers,
Allard
It’s fixed (and recorded here: http://issues.axonframework.org/youtrack/issue/AXON-92).
Cheers,
Allard
Awesome! Thank you 
What do you feel your rc3 timeline is like?
JAmes
Hi,
I’m building it right now. Should be synced with maven central within a few hours.
Cheers,
Allard