In terms of transactional retirement, the "issue" you highlight only applies to links for which we expect the broker to hold on to ... which, in the case of the JMS client, is durable subscriptions only. Moreover, since the client anyway cannot deal with restoring unsettled state, the client doesn't send its transactional dispositions unsettled (as Robbie has already pointed out), so the issue doesn't even occur.
What is the use case you see where being unable to send unsettled dispositions in a transaction would be a problem? In passing - I also agree with Robbie - I think transactional acquisition is a niche use case, and actually really hard to use. -- Rob On 6 February 2017 at 15:21, Robbie Gemmell <[email protected]> wrote: > Transactional acquisition is actually quite awkward, I'm not aware of > any client that uses it. Proton can't even support it currently I > believe. > > You need to know the transaction id before you flow any credit for it, > which adds extra round trips. When you then discharge the transaction, > any outstanding credit is not revoked, but it no longer applies to the > indicated transaction any more, meaning if you flowed more credit than > there are messages consumed in the transaction you now either need to > ensure that before you discharge there is no outstanding credit or > messages in flight, so more round trips, or perhaps revert to doing > transactional acquisition with the remaining credit/messages arriving > that arent consumed in the earlier transaction. Another thing to > consider is that with transactional-retirement, the 'failed' > deliveries during a rollback can as desired lead to the delivery-count > being incremented (via the default outcome; the JMS client indeed > doesnt send dispositions that arent settled when it is doing > transactions, or probably ever currently) whereas those that remained > live need not, though the client would then be free to do that of > course, but that would then require they be redelivered to the client > as already happens in the retirement case. > > Robbie > > On 6 February 2017 at 13:30, Oleksandr Rudyy <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
