On 22 March 2018 at 14:02, Gordon Sim <[email protected]> wrote: > On 22/03/18 12:32, Robbie Gemmell wrote: > >> On 22 March 2018 at 12:27, Gordon Sim <[email protected]> wrote: >> >>> On 22/03/18 12:07, Rob Godfrey wrote: >>> >>>> >>>> I think logically the transaction should be marked "rollback >>>> only" inside the broker. Any attempt to commit should result in error, >>>> but >>>> an attempt to rollback should succeed. >>>> >>> >>> >>> What if a client tries to rollback a transaction involving the >>> consumption >>> of from a queue that has since been deleted and publishing of those >>> messages >>> to another queue (which has not been deleted)? >>> >>> >>> >> Then the transaction will be rolled back and the related >> consumption+publish will not proceed, which is what the client >> apparently desires if trying to roll things back? >> >> (Not sure I understood the question..) >> > > I didn't ask the right question! > > One question is whether an explicit rollback would get an error (since > actually the messages will not remain on the original queue as that has > been deleted). > > Another question is whether you would permit the client to commit such a > transaction. > > To me, one consistent model to apply would be in the case of deleting a queue which has had messages "consumed" by an uncommitted transaction is that the queue deletion treats those messages as if the transaction had already rolled back (e.g. puts them on a DLQ or whatever), and then the transaction itself is marked as rollback only. Obviously there is an implicit serialisation here that says that deleting the queue is an atomic operation and while it occurs you cannot process transaction commits/rollbacks which affect messages on the queue (nor can you allow new messages on to the queue nor allow acknowledgement of messages during the 'delete' operation).
Another consistent model is to say that a queue cannot be deleted while there are associated sending or receiving links. -- Rob > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
