Hi @Anton, I like the idea, but using Transacted Sessions has a performance penalty - it’s best used for multiple messages that must all be processed as one blob.
Back to @Ashok, in your example of the database outage you have 2 basic choices: detect the database problem and close the application, or keep the application open and pause. If you close the application, the pending messages are implicitly nacked as @swenhelge mentioned. If you keep the application open, as @Aaron mentioned if you nack the messages they will simply be immediately resent to you, so that doesn’t help.
This is fundamental to a queuing based messaging: the queue is where your persistence is. All you have to do to be safe is not ack the message until it’s been received by the database. In this way all failure mechanisms are dealt with.
The only problem with this implementation is that you’re holding memory for the pending messages. If that really is a problem, close the flow, then when you detect the database has started re-open it and the pending messages will be re-delivered.