Clarify how something like a transactional outbox can be realized

[languitar]

The approach documentation gives some examples why message sending has to be performed in the same transaction as mutating entities to avoid state inconsistencies. This seems to get close into the direction of the transactional outbox pattern. However, from the current state of the document and further documentation I don't understand whether solving the same goals as for the pattern is in scope of the reactive messaging microprofile or not and if so, how this is realized. Maybe some clarification would help here?

[Emily-Jiang]

@languitar I think what you suggested related more in MicroProfile LRA. Please have a look at that spec to see whether you suggested can be incorporated in the future releases.

[languitar]

Interesting. I didn't know about that proposal.

Just to give you an idea why I thought this could be in scope of this specification: this is one of the quotes from approach.md that lead me into this direction:

In order for asynchronous messaging to achieve this goal of at least once messaging, it’s important that the developer doesn’t need to worry about ensuring messages are delivered to the message broker, but rather that the container guarantees that for them. Traditional imperative APIs that send messages via mechanism like invoking a method called send make it impossible to achieve this, since if the send fails, it will be left up to the developer to either retry or rollback the current transaction, and indeed it is impossible to both update a database and send a message to a message broker atomically.

Hence, an API where not just receiving messages, but sending messages are managed by the implementation, rather than the developer, is needed. The MicroProfile Reactive Messaging specification seeks to provide this.

[hutchig]

@languitar This could easily be a feature of reactive messaging in the future. In the underlying reactive streams terminology, multiple Subscribers on a channel would bring buffering of onNext(records), the delivery of which to a particular Subscriber is then gated by request(N) 'ticketing' from a particular subscriber. One could imagine then that such buffer 'flushing' could be delayed by the sender in some way. If one were to AND in the successful completion of the transaction under which the data was created then this would go towards a transactional outbox. https://github.com/smallrye/smallrye-event-sourcing#outbox-reactive-messaging-connectors

[languitar]

Btw, if there's a different pattern that also couples reliable event sending with database transactions I would also be happy if that was implemented instead of the transactional outbox.