Sagas: Tracking vs. Subscribing Event Processing

Imported from Google Groups
1

Hello!

I’m seeking advice on the pros and cons of configuring a Saga with Tracking Event Processing vs Subscribing Processing.

The idea of TrackingEventProcessors is appealing to me, as they ensure consistency without persisting the event and all projections in one DB transaction.
But how is consistency is guaranteed with Subscribing Processing in a setup with Axon 3.0, EventSourcing, Postgresql and Spring?
I assume a saga for a particular event needs to be persisted in the saga-store in the same DB transaction the event is persisted in.
Does the transaction also include the event created by a command sent by the saga?

Can someone, please, elaborate a bit on where the transaction boundaries are?

And I’m also curious why there is a TrackingEventProcessor for each Saga. For projections one create ProcessingGroups. Why is that no supported for Sagas?

Thank you for your explanations!
br Bernhard

2

Hi Bernard,

I’ve got several pointers on your question-set, but I find it hard to find the thread of continuity were you want to got with this.

So I’ll just give some feedback, and please give me feedback on my response as well, so that we can come to a conclusion on this. :slight_smile:

  1. You say you assume ‘an event for a saga is persisted in the saga-store’.

This is incorrect though. The SagaRepository stores the serialized version of a Saga. It does not store any events at all.

Hence you don’t have to think about how that would work transaction-wise at all.

  1. You ask if ‘the transaction of the event creation also include the command sent by the saga’. This wholly depends on which components you use to set up your system. Are you using a Subscribing or a Tracking Event Processor? If you’re using the Subscribing Event Processor, which EventProcessingStrategy are you using, synchronous or asynchronous? What type of CommandBus do you use to publish your Commands? The SimpleCommandBus, DisruptorCommandBus, AsynchronousCommandBus?

If we’d assume the default settings for everything, you’d have a synchronous SubscribingEventProcessor for you Saga, which will provide the Saga instance the event in the same thread which published the event (thus the active thread in your Aggregate). In the default set up, you’ll also have the SimpleCommandBus. If you’d use that CommandBus in your Saga, it’ll mean that the same thread which started the Saga (thus going back to the active thread in your Aggregate), will be the one publishing the command, but it’ll also be the same thread starting up the following Aggregate to handle that command.

Transaction wise this is all handled by the UnitOfWork behind the scene, which in it’s several phases will start/stop a Transaction. So if in the above set up we assume we’re using the defaults, the transaction will be started by the first command publication, which will remain the same throughout the Aggregate’s Event Publication, the Saga handling that and then the following command as well.

  1. You ask why we cant set processing groups for our Sagas. That exact same question popped up on Stack Overflow quite recently, from which a GitHub issue was created. We’re still discussing the pros/cons to this. If you’ve got any valuable input why we should allow Sagas to be set into Processing Groups just like Event Listeners, that would be much appreciated.

Hope this gives you some insights and as pointed out earlier, feel free to ask follow up questions based on my response.

Cheers,

Steven

3

Thank you Steve for your response. And please excuse my late one.

Let me reply point by point.

  1. I had a look at the linked github issue. It seems to be scheduled for Axon 3.3. Thats great!

  2. Your assumtion with defaults nailed it. Thanks for you explanation. That makes a lot of sense. I get that part now.

  3. I guess I have formulated that poorly. Of course a serialized version of the Saga is stored to the SagaRepository. What I’m interessted in, is when and under which circumstances the Saga is serialized and written to the SagaRepository. Is it possible, that a Saga is never persisted in the SagaRepository even if it was executed?

Thank you for your explanations Steve.
Cheers Bernhard