I would argue that durability ACID property would be violated if transaction would be allowed to discharge successfully when queue is deleted before the transaction end.
Though queue is not a direct transaction participant, I would expect that settling of unsettled deliveries should fails or end-up in rejected outcome on source/target disappearance. As for the settled deliveries, I believe that transaction behaviour should be the same as the one defined for publishing of pre-settled messages via anonymous relay when destination does not exist ( As per [1] the transaction should be marked as rollback only). Kind Regards, Alex [1] https://issues.oasis-open.org/browse/AMQP-140 On 21 March 2018 at 13:46, Alan Conway <[email protected]> wrote: > On Tue, Mar 20, 2018 at 9:07 AM, Oleksandr Rudyy <[email protected]> wrote: > >> I think that publishing/consuming transactions should not be >> committable after queue deletion. >> > > To play devils advocate: the transaction is isolated (the I in ACID) and > queue deletion is outside the scope of the transaction. > Consider these sequences: > > tx-start, send message, tx-end, queue deleted > tx-start, send message, queue deleted, tx-end > > The observable state of the system is identical after both, and since > deleting the queue is not part of the transaction, the ordering of the > queue deletion with respect to the transaction boundaries is irrelevant and > the transaction should succeed in both cases. The transaction only > guarantees that the message reach the queue (atomically with other > transactional activity), it guarantees nothing about the life-span of the > queue with respect to the life-span of the transaction. > > > >> As a developer of messaging solution I would find it odd to be able to >> commit transaction successfully after queue deletion (even when all my >> messages settled and reached terminal state). >> Though, I would expect to complete rollback successfully in this case. >> >> I think that such behaviour would be least surprising for the end users. >> >> Though, I am not sure what behaviour should be when messages are >> published via exchange and routed into deleted queue >> >> >> >> >> On 20 March 2018 at 11:37, Rob Godfrey <[email protected]> wrote: >> > On 20 March 2018 at 12:30, Gordon Sim <[email protected]> wrote: >> > >> >> On 20/03/18 11:13, Oleksandr Rudyy wrote: >> >> >> >>> I think than on queue deletion the Broker should do the following for >> >>> AMQP 1.0 endpoints >> >>> * send DETACH performative with an error "amqp:resource-deleted" to >> >>> all attached links >> >>> * delete all information about detached links >> >>> >> >> >> >> That is what the c++ broker does. >> >> >> >> >> >> >> > How do we treat transactions which have transactionally enqueued a >> message >> > on the (now deleted) queue - do we allow them to commit successfully, or >> do >> > we force a rollback? Similarly when a message has been sent from the >> queue >> > and accepted as part of a transaction? >> > >> > -- Rob >> > >> > >> >> --------------------------------------------------------------------- >> >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
