Extract events applied after command handling

Imported from Google Groups
#1

Hello,

I am looking for a way to check the events that were applied after command handling is completed but before the events are persisted into the event store. If I find none I would like to be able to apply one.

I was looking to do this with a MessageHadlerInterceptor, but I have not been able so far to extract such information from there (if it is even possible…)

Any ideas?

Thanks,
Armando.

#2

Hi Armando,

My hunch is that the MessageHandlerInterceptor isn’t the way to go, but then again, I am not sure what you need this solution for.
Do you mind sharing the use case why you want to achieve this? From there on I assume I/we can give you better guidance.

Cheers,
Steven

#3

Hi Steven!

So basically if the processing of a command in an Aggregate does not produce any events, I would like to apply one. I am at the moment investigating @CommandHandlerInterceptor from where I can apply events (I couldn’t from a MessageHandlerInterceptor. But I only want to apply it if the command processing did not apply any others. That, or at least be able to apply the event after the rest of events have been applied (if any). At the moment I can only apply the event when the annotated method is called, which is before the actual command execution…

Thanks!
Armando

#4

A bigger picture of the problem… We have several instances of a given application, we are not using a DistributedCommandBus, instead we’re using a distributed cache. We have found that there are some cases where a given command is executed with a stale version of the Aggregate. If that command execution generates events, it’s fine since there will be a concurrency exception thrown when inserting the generated events in the database. We will recover from this error by retrying the command with the correct version of the aggregate.

However, we have a very edge case where the stale aggregate would make the command to not apply any events when it should have. No errors will be generated so we cannot recover from that. Under circumstances where no events are applied, we still want to apply one dummy event that will act as a protection mechanism to detect that we actually handled the command with a stale version of the aggregate.

Hope I was able to summarize the problem more or less…

#5

Hi Armando,

I have to say that it feels like you’re crawling down a rabbit hole to resolve an issue. Are you sure you want to be emitting (and storing) artificial events just to resolve an issue that would also be resolved by using a DistributedCommandBus? It feels like the solution adds a lot of incidental complexity.

But… if you do want to pursue this path, one way you could do it, is by creating a CommandHandlerInterceptor inside your aggregate. You can define a method inside the aggregate and annotate it with @CommandHandlerInterceptor. Make sure you define “InterceptorChain” as one of the parameters. In that method, use getVersion() before interceptorChain.proceed() and after. If the versions are identical, no events were applied. In that case, you can do another apply().

Cheers,

Allard

#6

Hi Allard,

Thanks for the reply. Yes, after running into this and looking at the options I was actually already considering moving to a DistributedCommandBus, I’ll bring it up with my team.

In any case, thank you for the workaround you suggested I’ll also try it out since it should be quick!

Regards,
Armando.