I need a cluster implementation of my listeners that use a sequential policy : when a listener method is invoked, other listener on the same cluster must wait the end of the current running listener method. Indeed, this listeners make update on database sometimes on the same tables (no transaction ).
AsynchronousCluster allows easily this behavior, but my problem is that this cluster must be also replayable, and replaying an asynchronous cluster causes some bugs because my listeners need to implement ReplayAware in order to make some actions only if the cluster is not in replaying mode. When i replay on asynchronous cluster, the methods beforeReplay() and afterReplay() are called successively, while replaying is still in progress.
If i use SimpleCluster to resolve replaying problem, i notice that this cluster does not manage the sequential policy : if an event are triggered by command in an other thread, multiple methods in the same listeners can be called in the same time.
What is the best solution ? I thought to write a SequentialSimpleCluster, which is the same implementation of SimpleCluster, but adding synchronize keyword to the method “doPublish”, but i’m not sure that is a good solution.
I guess this is a limitation of the current replaying structure.
However, there is one thing unclear to me. If your requirement is that one listener is invoked after another, then every cluster will do that. The sequential policy is about concurrent execution of different events. Thus, one event must be handled, before the next is picked up. Which of the two do you require?
it’s not about listener class, but at the method (handler) level inside listener.
I have two kinds of event listeners, one dedicated to update read side, and an other which react as a simple saga : when a event is raised, it sends a command, the aggregate apply events which are treated by the first listener. If my listener is in SimpleCluster, two methods of this listener (so two different events) can be run at the same time :
Event A handler begin
Event B handler begin
…
Event A handler end
Event B handler end
This situation must be absolutely avoided in my case, because the handlers for event A and for event B can sometimes update the same database table (mongodb collection actually).
If i use Asynchronous cluster, i always have the good behavior :
Event A handler begin
Event A hanlder end
Event B handler begin
Event B handler end
But the problem of Asynchronous cluster is for replay events… And the fact that the cluster is asynchronous is not a requirement.
Actually, i need a SimpleCluster which is thread safe, to ensure that even if two different threads publish events (one which react to a user command, an other which react to simple “saga” process), the sequential policy is observed.
I hope i was clear, because my english is not very good.
in the “SimpleCluster”, sequential access is only guaranteed on the thread level. If multiple threads can deliver events in parallel (which is possible when events come from different aggregates), then you must handle sequencing yourself. The simplest (but not cheapest) way to do so, is by making these methods synchronized.
The pre- and postreplay issue on the async cluster is one that should be fixed. I’ll have a look at that.
Cheers,