I have been using Axon for some time now to implement the Command Side of my application. In prototyping, the implementation seems to work well in processing commands that are issued by remote clients over JMS (Active MQ).
Initially, I only needed a single thread to process messages from the internal JMS session queue - so aggregates are fetched, updated and persisted in the same thread that polls the queue. (I am using GenericJpaRepository with Optimistic Locking)
What it is clear is that as the number of message producers grow - I am going to need to employ multi-threading, which is causing lots of problems with writing to my aggregates. Pessimistic Locking slows the application down tremendously and Hibernate does not like many threads updating different attributes on my aggregate (part of your concurrent modification checking using versioning I assume).
I know that one of the big questions to ask yourself when implementing Axon is whether the application would expect more queries that it would writes to the database. Initially, I thought this was the case - however it is clear now that my system will in fact be expected to perform many writes every second (this includes some pretty heavy business logic).
I want to carry on using Axon but I would like your thoughts as to how I might be able to get more out of the command side. The messages I am processing are real time location messages which get updated every 5 seconds or so. When I receive a position update, I update the aggregate in the repository, generate the state changed event and then an Event Handler will invoke logic between other ‘moving’ aggregates based on the state change. As many as 1000 ‘movable’ objects could update their position every second.
Because I get an updated position so often, it makes me wonder whether I need a repository at all. A simple in memory map of my ‘movable’ objects with the latest position stored so that BL can be applied could be sufficient.
Sorry to ramble on, if you have any thoughts of how best to employ Axon for this business case I would appreciate it.