I just have some random questions that have come to mind as I work on the Axon configuration.
Is there a preference when it comes to an EventStorageEngine implementation?
What kinds of things might I take into consideration when deciding to use either JPAEventStorageEngine vs MongoEventStorageEngine?
For the MongoDB implementation, how would I replay events?
Typically, we prefer to create tables ourselves, so is there a prescribed method for creating event store tables or is it something where you would let hibernate create them, then take the create scripts and modify accordingly?
Is there only supposed to be one event store or is it more of a “depends on your requirements” kind of thing? eg. 1 per service
Are there any plans to add more support for configuring the event store in Spring Boot’s yml/properties file? Not that it’s really difficult currently, but just curious is all. Here’s what my config looks like at the moment:
in practice, we have seen by far the best results using a relational database as an Event Store (besides our own Event Store Server, obviously). Mongo is nice, but doesn’t really fit nicely with Tracking Processors, for one. It will work, but isn’t efficient. Furthermore, the lack of (cross document) transactions, makes it awkward to use, at times.
As for how many instances of Event Stores you’d need, I can only say “it depends”. There are many factory at play here. Performance requirements, data volume and event reach, just to name a few. In general, one could say that one instance (i.e. cluster) for each bounded context would be a reasonable starting point. If events cross context boundaries, you want to be very careful about the exact events you’re sharing. Probably, the detailed events used in one boundary don’t have much value in another. It is likely that you want some more course-grained, higher abstraction level events shared between contexts.
If you do need a service to read from two contexts, you could use a StreamableMessageSource that reads from two backend streams and combines them into one. Such a thing isn’t available out-of-the-box in Axon, but also not very hard to create either. If you need to wander that way and something isn’t available yet, I can guide you through it.
Regardless of the Storage implementation you choose, replays always work using a Tracking Processor. By deleting the token owned by that processor, you force it to restart processing from the beginning of the stream, effectively triggering a replay. In future Axon version, we will provide means to programmatically do this. For now, you’ll have to unleash some SQL on your database…
Just a few more questions now that I’m going to just use the JPAEventStorageEngine…
If both the command-side and query-side are in the same app and both are using JPA, are the event store and query models intended to go into the same database?
I’m using Spring Boot and I’ve read about configuring multiple JPA datasources. Assuming that, ideally, they should not be in the same database, do you have any suggestions for configuring the JPAEventStorageEngine to use a non-Primary datasource?
generally, one would put the Event Store and the view models in the same database, but this is in no case a requirement. Especially when multiple services share an event store, you would not want them to also share the view models. In such cases, having a dedicated Event Store is a good choice.
Axon uses an EntityManagerProvider to obtain the EntityManager to use for the JpaEventStorageEngine (As well as any other Axon components that uses Jpa). The default EntityManagerProvider uses an EntityManager from the persistence context. If you have multiple contexts (which you would when putting the event store in a different database), you might have to create a slightly different version of the ContainerManagedEntityManagerProvider yourself.
Also make sure the Transaction Manager (the one used by Spring) manages the transactions in the right data source(s).
Other than that, Axon just uses Jpa, so everyting else is configured in Jpa as you would with any other application.