-
Notifications
You must be signed in to change notification settings - Fork 216
C++ Local transactions #442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
I've spent today carefully considering the behaviour of the code and API design with respect to message settlement and disposition under various conditions and I've concluded that the API and implentation currently does not offer the required support for a transactioned API. Specifically:
Settlements aren't handled correctly - the basic reason you'd want transactions in the first place implies that you need to delay settlement until after transaction commit, but our code does not do this - it doesn't even acknowledge you'd want to do this.
|
|
We also need some way of testing the error/unhappy cases - so the transaction tester needs to simulate a broker failing commit and also doing some things that are illegal in the AMQP transaction protocol. |
c276b7b to
184806f
Compare
I think this needs quite a lot of work to make it useful, but it is a start.
A potential null pointer access, and a memory leak on error condition
184806f to
a3e4fd4
Compare
|
I've done a lot more work on this now, and I'm getting a lot happier about the correctness of its behaviour for outgoing messsages. I think the settlement behaviour for these is now correct under successful commit and also rollback. I've enhanced the python broker some more and I think it now actually represents most of the transactional behaviour of a spec correct broker. It would be good to add a way to make it fail to commit - perhaps adding a transaction timeout timer would be a realistic way to do this. |
Rollbacks shouldn't settle incoming deliveries.
We added new callbacks for transactioned delivery updates. These have a different meaning from the regular delivery updates as they are provisional on the transaction successfully committing, so should be separate callbacks.
Also fleshed out the behaviour of the callbacks and tightened the settlement behaviour for outgoing messages on transaction aborts.
Add option to send a bad message (with no 'to' address) which should force the broker to reject it. Add an option to rollback a transaction after a certain number of messages.
f8e9918 to
9db81aa
Compare
Also rollback shouldn't requeue transactionally updated outgoing messages.
This is the work in #437 just about ready to be merged.