Can anyone explain below statement in detail (this is from Guaranteed delivery guide for developers but nothing much on this subject)
“You can only use the guaranteed delivery capabilities with stateless (that is,
atomic) transactions. As a result, guaranteed delivery capabilities cannot be used
with multi‐request conversational services.”
One more thing : has anyone used TContext API or IS services (pub.remote.gd:start, pub.remote.gd:invoke, pub.remote.gd:end) specifically to control transactions ?
Transaction which does not maintain its state is known as stateless transactions, such as select query of database, insert query, commit…etc.
Guranteed delivery helps in the only case of transient failure. If transaction is not stateless or transaction maintains some state then in that case if transient error occures and when error is corrected by that time transactions which maintaince their state will loose their state and then it will be meaning less to redeliver that transaction. As transactions which maintains state are depend upon other transaction or maintain their state for handshake process.
So once connectivity gone transaction loose its state and session so if you resume the delivery such transaction using GD it has no meaning.(For example: If you are using AS2 delivery and expecting MDN is same session or synchronous MDN and while sending MDN you face transient error and you try to resubmit the MDN after restoring the network then resubmit of MDN will be useless as synchronous MDN should be delivered in same https/http seesion which goes off with transient error.)
On other hand if transaction is stateless then it has no impact if you resubmit them after restoring the session.