Are modulith events locked by modulith runtimes during listener invocation?

[masch712]

I have a modulith application running in a docker container, and I want to scale it out horizontally (i.e. run more docker containers, all connected to the same database).

The PersistentApplicationEventMulticaster bean's afterSingletonsInstantiated method retrieves incomplete event publications from the database by calling registry.get().findIncompletePublications(), then for each event publication, it calls the respective listener via publications.forEach(this::invokeTargetListener).

There doesn't appear to be any locking at the database level going on here, so if multiple modulith runtimes (eg. docker containers) are starting up around the same time, they may attempt to invoke the listener for the very same event publication together. Do I understand that right? Another way this could happen: If container A publishes 100 events, and their listeners are all in progress handling those events while container B spins up and queries for incomplete publications.

Some potential approaches to prevent this:
A. Pessimistically lock the event publication row on retrieval in findIncompletePublications
B. Each modulith application context could "claim" the event publications it intends to invoke before it actually invokes it.

• This could be achieved with a new column in the JpaEventPublication entity like "executorId" whose value would be some identifier for the modulith runtime currently executing the listener
• Another column indicating an expiration time on the claim would probaby also be valuable here
• Transaction management in the SPring Events ecosystem might be a little tricky here; we'd need to commit the "claim" to the database before we actually start invocation, I think.

[odrotbohm]

The republication on startup was switched to be disabled by default in 1.1 for exactly that reason. There's also the IncompleteEventPublications API now that allows writing custom code to control when which publications are supposed to be republished. A common way of dealing with those in a multi-instance deployment is to use a tool like SchedLock to make sure only one instance processes incomplete events.