On 22 March 2018 at 12:55, Robbie Gemmell <[email protected]> wrote:
> On 20 March 2018 at 12:44, Gordon Sim <[email protected]> wrote: > > On 20/03/18 11:37, Rob Godfrey wrote: > >> > >> 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? > > > > > > It seems the c++ broker allows the transaction to commit at present. I > don't > > think that was a conscious choice though. I suspect the scenario wasn't > > explicitly planned for. > > > > I think the ideal behaviour would be for a transaction error to be > signaled > > regardless of whether the client initiates a commit or rollback in both > the > > publish and consume case where a queue involved has since been deleted. > > > > From the spec: > > > > "If the coordinator is unable to complete the discharge, the coordinator > > MUST convey the error to the controller as a transaction-error." > > > > To me if the queue is deleted, the transaction can't really be properly > > completed, therefore and error would be clearest. > > > > > > I dont think an error should be signalled if the controller is trying > to roll back the transaction. The queue not being there anymore doesnt > seem to me like it really prevents discharging an attempt to > rollback/fail a related transaction. That may for example something an > application/client tries to do if some associated link(s) have just > been remotely closed. > > I agree - 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. -- Rob > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
