Inquiry on transaction operation for request response link

[minghuaw]

I didn't find an official definition for transaction operations for the request-response link (management link) in the AMQP management working draft. I have looked at how RequestResponseAmqpLink handles transaction, and it seems like only the send operation carries the transaction ID, and the transaction itself is committed after the response is received and processed.

I would just like to confirm if my understanding is correct.

[vinaysurya]

Hello @minghuaw, yes your understanding is spot on. Basically as part of a RequestResponse operation, we first check if its a part of transaction. If it is, then first we enlist in the transaction (i.e controller called Declare to get transaction id) . Then as second step of the RequestResponse Operation, we execute the actual operation, by including the transtion id in it. This execution is sent over the sendinglink which is what you are referrring to, Then that particular operation is completed. After all operations of transaction are complete, then the application can call Commit, at which point the Discharge is sent to the Service and the transaction can be committed. This is a file that has some of the details for reference:

https://github.com/Azure/azure-service-bus-dotnet/blob/1607601d3d3c6cf7e0c2a757ccb398d803482e7c/src/Microsoft.Azure.ServiceBus/Amqp/AmqpTransactionEnlistment.cs

[minghuaw]

I have a follow-up question. I was testing this transaction request-response operation on a Service Bus queue, after a transaction posting, the disposition frame sent back from Service Bus carried a regular Accepted delivery state instead of a transactional delivery state.

<type name="transactional-state" class="composite" source="list" provides="delivery-state">
    <descriptor name="amqp:transactional-state:list" code="0x00000000:0x00000034"/>
    <field name="txn-id" type="*" mandatory="true" requires="txn-id"/>
    <field name="outcome" type="*" requires="outcome"/>
</type>

I was expecting a transactional delivery state since this is considered a transactional posting operation; however, the spec indeed lacks formal definition for transaction operations for management links. I was just wondering if this is something that is defined in some internal working draft?

[xinchen10]

Request-response operation is not message transfer. The transaction-id, if any, is part of the request message, and the response message tells the final state of the operation. It is a layer on top of AMQP message transfer.

[minghuaw]

Request-response operation is not message transfer. The transaction-id, if any, is part of the request message, and the response message tells the final state of the operation. It is a layer on top of AMQP message transfer.

@xinchen10 I was not referring to the response message. I was referring to the Disposition message that follows the request message. I think what the spec asks is that the disposition should carry a transactional delivery state because the transaction is not committed yet

[minghuaw]

@xinchen10

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#section-txn-work

When traveling in the other direction, from resource to controller, the transfer and disposition frames indicate work performed, and the txn-ids included MUST correctly indicate with which (if any) transaction this work is associated.

[xinchen10]

As I said request-response is a layer on top of message transfer. Transaction state is in the message content, not on the transfer and disposition frames. Disposition for the request message means that the request has reached the service but the outcome is unknown yet, and that will be in the response message.

[minghuaw]

I don't think that request-response being one layer above the message transfer has any conflict with the core spec. The problem I was raising is that the disposition I got after a transaction posting carried a non-transactional delivery state, which doesn't seem to be compliant to the core spec.

[xinchen10]

I take back what I said about the transaction behavior of the SB request-response. That was my understanding of how it SHOULD work but it might be outdated or completely incorrect. It would be better to clarify the issue with the SB team.

[minghuaw]

Thanks. I will open an issue there then.