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] > >
