Is DistributedCommandBus Necessary...

Imported from Google Groups
#1

I have an application that will be receiving messages via ActiveMQ and the handlers for these messages will be sending commands via the command gateway. I have read that the event store will use optimistic locking to make sure that the aggregate state (I’m using @EventSourcingHandlers) stays consistent. Do I need to use “consistent routing” to send all commands for a specific aggregate to a specific instance of my application? Do I need to set up the DistributedCommandBus? Or, will simply using a local command bus and the optimistic locking suffice? Obviously all instances share the same RDBMS-based (JPA) event store.

Thanks,

James

#2

I think the short answer is yes, you have to.

We do not have it yet but we get exceptions , mainly because of the event sequence already used on the other instance. We do a retry in this case, but this leads to gaps in the global identifier in an RDBMS based solution.
Wil are planning to axon server for that reason.

Gerlo.

#3

Okay, thanks. That’s what I thought.

I’d like to start using Sagas. I’m trying to wrap my head around exactly how “remote” folks would participate in the Saga, though. Do they register a @SagaEventHandler and connect to the DistributedCommandBus so that they can take part in them? Does that also mean they need to have access to the same database for the EventStore? I’m trying to come up with a low-barrier-to-entry approach to taking part in these Sagas, hence using ActiveMQ (something we already use for infrastructure). I hope I’m making sense. I’m very new to the Axon framework and perhaps I just don’t quite grok how everything fits together yet. Thank you for your time.

James

#4

Hi James,

as Gerlo states, the exact anwer is No, not needed, but yes, recommended. In systems with high concurrency, you’re likely to get a lot of failed optimistic locks, reducing the efficiency (high cpu usage and high latency) of your application.
For Axon components, it doesn’t really matter what type of command bus they interact with. It’s all transparent.

The biggest “challenge” is to make sure that all events, regardless from the node that published them, arrive at the Saga. By far the easiest solution, is to make sure the Saga is in a Tracking Processor, reading events as they are stored in the (shared) event store.

I hope this helps you further.
Cheers,

Allard