Thank you very much. I try to summarize my alternatives.
(I am assuming a simple application with single eventbus and single event and saga jpa repository.)
- Use THE global event bus.
I use the same event bus (THE event bus) that my aggregates publish events on and that the sagas listens on
to send the response(s) of my as events to the sagas.
I tried that and if I interpret the errors correctly I have to add a @Transactional annotation because my response events are
persisted in the database like “normal” aggregate events are.
Is that interpretation correct?
It feels wrong to me storing this kind of events because they are just events of an request-response cycle and are not (yet) relevant
for changing the state of something. The saga should decide what and if some storage changing command is generated.
- Use THE SagaRepository instance directly.
By using this I get storage of sagas for free including locking for synchronized access with THE eventbus events.
I expect that I have to provide a transaction context, too, because of the JPA-Nature of saga repository.
I will give this a try.
Because of the way sagas are typically executed synchronously within database transactions I assume the
rules for DB transaction apply normally:
Don’t execute long-running synchronous calls.
Please correct me when I am wrong!