JMS 2-way communication, doesnt make sense to make transactional in some cases?

[Jesus Angeles]

Hi,

'2-way' means (synchronous, like calling a method, or remote procedure call).
I send a message to queue 1, and in few seconds (10 second limit), I must receive a reply to the message at queue 2 (sent by another service as reply to my message).

SEND.
Because the 'send' part must be committed (transaction), so that message will be sent and receiver can retrieve the message, then there is no need to put it in a transaction. Is this correct?

RECEIVE.
In the 'receive' part, if and only if my business requirement never needs me to put back a message into the queue (e.g. failed processing), then I do not need to put it in a transaction. Is this correct?

SUMMARY.
Because in my business requirement, the 'receive' does not need to put back the message in any scenario, then I dont need to put neither the 'send' nor the 'receive' in a transaction. Any comment, e.g. if this is bad?

[A.J. Côté]

Hello,

I think there are 2PC/3PC (double/triple phase commit) transaction managers that could make the whole process transactional.

Otherwise, it is usually simpler to commit both messages individually and design handling of the use cases at the application level if feasible. But yes, still use independent transactions unless you can't see any downside in not using them..

[Jesus Angeles]

I made them non-transactional.