True, thats not something I had considered. As I say, in general I also think failing the commit is the way to go, even for the cases where it doesnt make a difference in the end.
Mainly though I think that noone should be letting queues disappear on the fly :) On 22 March 2018 at 12:26, Rob Godfrey <[email protected]> wrote: > On 22 March 2018 at 13:11, Robbie Gemmell <[email protected]> wrote: > >> While I lean toward failing the transaction if an attempt to commit >> was made, when I started reading the thread just now I did also think >> of essentially the same as below before I got to Alans mails. At the >> end of the day whether the transaction succeeds or fails the end >> result to the users is actually still about the same, the messages in >> question no longer exist since the queue no longer exists. However I >> do think its better to fail a commit attempt since we never actually >> got to make the changes on there because it went away. >> > > One thing that may differ between deleting the queue before the transaction > is committed vs. after is any sort of DLQ behaviour; e.g. if the queue is > deleted after commit, then the message may be moved to a DLQ... but if the > queue is deleted first, will commit the transaction still cause the message > to enqueue into the DLQ. These sort of ambiguities are why I prefer > rejecting an attempt to commit the transaction. > > -- Rob > > >> >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
