I was wondering about the consumption of messages from the queue:
In the current example you first check if the message exists by id and then return if it does.
Isn't it theoretically possible for the same message to arrive twice at the same time, thus bypassing the 'existsbyid' check twice and therefore - executing the business logic twice?
Is this something you would want to consider in a production app?
hey Petar, thanks for the point you are making! Really good question. You are basically worried about a race condition in the consumption service, in the inbox table.
since we are wrapping the processor in a transaction, that will basically guarantee all-or-nothing. Adding to that, I forgot to mention in the article itself, we must set the eventId in the inbox table as Primary Key. This will basically make sure we persist the event once and upon a second try to insert the second transaction would abort with constraint violation!
Hey Konstantin, great post!
I was wondering about the consumption of messages from the queue:
In the current example you first check if the message exists by id and then return if it does.
Isn't it theoretically possible for the same message to arrive twice at the same time, thus bypassing the 'existsbyid' check twice and therefore - executing the business logic twice?
Is this something you would want to consider in a production app?
hey Petar, thanks for the point you are making! Really good question. You are basically worried about a race condition in the consumption service, in the inbox table.
since we are wrapping the processor in a transaction, that will basically guarantee all-or-nothing. Adding to that, I forgot to mention in the article itself, we must set the eventId in the inbox table as Primary Key. This will basically make sure we persist the event once and upon a second try to insert the second transaction would abort with constraint violation!
hope this answers the question! Again, great one!