Locking mechanism on event publication

[gquemener]

Hello,

First, thank you for this tool.

I believe it brings modules as a first class citizen, and helps to fill a knowledge gap in the software engineering community (especially in Java, but I already see how it could be ported to other ecosystems) : how to design and enforce service/module/component boundaries, and still be able to adapt them to the knowledge evolution of the problem space (moving to physical boundaries when it makes sense).

You are helping the architecture world to be less "big ball of muddy", and more modular, and that is awesome!

I have noted that the SQL queries that are performed in order to extract events to publish do not use locking mecanisms (pessimistic or optimistic).

As a consequence, it poses a risk of race condition when publishing incomplete events with multiple threads/instances running, doesn't it?

Spring Integration has such locking (see Postgres and MySQL, for example), though the SQL Server implementation seems to lack it.

Is it a design choice, or a lack of time, to implement such feature?

Apart from a couple of related discussions(1), which do not mention database-level pessimistic locking, I haven't seen any trace of such limitation, or a disclaimer in the documentation, and I'd be happy to contribute in this direction (and also to make publishing more concurrent friendly).

(1) here and here

[odrotbohm]

Find a bit of information on the revamped Event Publication Registry we introduced in 2.0 here. In short, there's a new state RESUBMITTED that the resubmission logic will flip the publication to, and only application instances that actually update the row will continue to process the publication.

I guess we'll have to revisit the docs to make that more obvious. EDIT: I filed and fixed GH-1593.