Set based consistency: event processor versus event dispatch interceptor?

I’m making use of the suggestions posited by Yvonne’s excellent blog entry on set-based validation to create an annotation-based framework in my project to enforce uniqueness. I’m using a parameter resolver on the command side to test for uniqueness, but this question is for providing values to the lookup table.

The blog suggests using a event processor configured to run in subscribing mode so that it always executes in the thread that published the event. In the documentation, it appears that event dispatch interceptors also run in the thread that publishes the event, and it’s a simpler interface to implement against.

What would be the consequences of implementing this in a dispatch interceptor versus an event processor? Are there potential gotchas that would be avoided with a subscribing event processor?

Hi Jesse,

Thank you for your compliment. I am in the process of changing the blog a bit and make the event processor tracking (or you can also use the PooledStreamingEventProcessor for better performance). To come back to your question, a dispatch interceptor does its work before the transaction starts (before the UOW), so in case the value is saved there it could very well be that the command fails later on.
To make things a bit easier and not needing the UOW you can take a look at my PR. There I use a tracking event processor. If the event processor is replaying a command is rejected to prevent duplicates.
I hope this helps,



I have the message interceptor registered to the event bus, so it should be occurring after the command processes but before the event is persisted. That’s what I’ve been able to observe so far when debugging, at least.

@Yvonne_Ceelie, I looked at your updated sample code. I like the idea of being able to do a replay to repair the lookup table in case of data corruption, but I was curious, is there a way to create an event processor that runs against all events? The way I’ve written my code is to enforce uniqueness using annotations, and currently my code scans the event entity to see if it’s been annotated and, if it has, then to perform the data sync against the lookup table. Should I rewrite it to use an event handler interceptor?

Oh, I see, you mentioned the dispatch interceptor that gets invoked before a message is handled, a message interceptor gets invoked after a message has been handled and then you can use the UOW.
But I doubt this is the right way to go. Interceptors can be used for validation or to add metadata. Updating views is not what they are meant for.
So I would advise using an event handler. To answer is there a way to create an event processor that runs against all events? Yes that is possible. The first parameter of an event handling method is the event message so what you could do is;

public void on(GenericEventMessage event)

Or make use of inheritence and create a parent event and add an event handler for it.

Let me know what you think about that.


That would work perfectly! I’ll try it out and see how it works.