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