Unit of work with command handling and event processing

I understand the axon uow can be tied to the transaction manager, and in the case of db transaction, it will honor it (in most cases). However I am still not quite clear about the demarcation of the uow.

First of all, is there a transaction concept involved with event handling? (I am not talking about the eventsourcinghandler invoked by apply(), that is tied to persisting the aggregate and is invoked by command). So during normal event handling, default behavior for exception is just log and continue. Only failure in the event processor will cause retry later (token release and reclaim), but that is my concern described later.

Secondly, if that is all the transaction concepts related to event handling, then let’s focus on command handling. Axon docs says by default only runtime exception will cause the retry, however that is not automatic from what I am seeing, I have to specifically configure the retry handler (Interval in my case, btw, the doc is very confusing, it says NonTransientException at one point, and I do verified the source code is actually checking NonTransientException instead of RuntimeException). So where is RuntimeException involved?

Thirdly, what happens if an event handler issues a command, and the command failed, I believe by default, the code will just happily continue. (Someone please correct me if I am wrong). On the other hand, if a command handler sends an event, as long as the event is successfully stored in the event store, the command is successful.(regardless the following event handling). The thing really confuses me is: if the command handler(I configured a interval retry handler) is on Aggregate instance, and the aggregate is using eventsourcing handler to apply() an event, and somehow this step failed, this will cause retry to happen (60 seconds?), so what about the retry handler I configured on command handler, when or will it ever be invoked?

Sorry for the long post, Any experts to either confirm or correct my understand? Thanks in advance.

Hi Chun,

the RuntimeException part is involved in deciding when to rollback a Unit of Work (and its transaction). By default, checked exceptions are considered business exceptions and will not cause the UoW to be rolled back. Yes, you do need to configure a retry handler, but then exceptions are retried if they aren’t explicitly non-transient.

Event handling is also executed in a transaction. You can configure what needs to happen when handling an event fails. The processor can either ignore and move on, or go into retry mode, releasing its token and retrying after a second (increasing the wait time on successive failures).

If an event handler issues a command, this is generally asynchronous. You get a completable future that allows you to wait for the result and even “fail” the event handler if you like it. If you ignore that result, the event handler will be considered “successful” when handling completes.

Hope this clarifies things.