Hi, I would like to ask why "transactional retirement" is used by jms client instead of "transactional acquisition"?
I am sorry if I missed any previous discussion about implementation of amqp transactions with JMS client. From my point of view the 'transactional acquisition' model would fit better the stateless nature of JMS client. The reason why I am thinking so is that with "transactional retirement" any unsettled messages would remain acquired on transaction rollback as per section 4.4.2 "Transactional Retirement" last sentence "In the event of a controller-initiated rollback (a discharge where the fail flag is set to true) or a resource-initiated rollback (the discharge message being rejected, or the link to the coordinator being detached with an error), the outcome will not be applied, and the deliveries will still be “live” and will remain acquired by the controller, i.e., the resource can expect the controller to request a disposition for the delivery (either transactionally on a new transaction, or non-transactionally)", or as per 4.4.4.2 "Transactional Retirement"( "Delivery Sent Unsettled By Resource; Controller Does Not Settle"). It seems that JMS client should never send disposition for unsettled transfers in transaction. Otherwise, if link is detached without close=true, the transefered message would be in acquired state and if JMS client will not reattach the link, the transfers would be acquired forever. Out of curiosity, why 'transactional acquisition' is not used by the jms client for jms transaction implementation? It looks to me like a more attractive approach when client does not keep the states. Am I missing something? Kind Regards, Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
