I do appreciate the logic in Allan's suggestion, but it still feels weird the transaction would apparently succeed even though the messages were lost. I like the idea of marking the transaction 'rollback only'. I agree that if the transaction coordinator actually rolls-back, the roll-back should proceed without failure.
On 22 March 2018 at 12: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. > > 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]
