• Post Reply Bookmark Topic Watch Topic
  • New Topic

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

 
Jesus Angeles
Ranch Hand
Posts: 2069
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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é
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2069
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I made them non-transactional.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!