scalar-labs
Quick suspend support. Enable tx.suspend without xaresource.end
The current implementation of suspend in btm is to communicate with all resources to end the current transaction. Resume then also communicates to all resources to re-enlist in the suspended transaction.
Other open-source transaction-managers do this in a much simpler way. They simply move aside the current transaction (by nulling the current theadcontext), clearing the way for a new transaction to continue in its place. Resume is then only a matter of restoring the original transaction in the place it was in.
Since suspend is a necessary part of a requires_new transaction boundary efficiency is very important; the current implementation feels weighty.
I'm certain that the current approach was selected to help with more complex usecases than a simple requires_new; could you tell me more about that?
Finally, i don't think this commit is in a state that its ready to incorporate into the main. I would like to add a few unittests that target the functionality - but i just wanted to start a conversation, and i figured that would be easiest with some starter code. Fwiw, this is operating well on my current system (which is quite large).
I'm not against adding this new feature in, I'm even considering making it the default behavior.
The way BTM implements transaction suspension is a tradeoff between XA spec compliance and pragmatism: the spec mandates that start and end have to be called with TM_SUSPEND and TM_RESUME flags but too many resource drivers do not support this so this alternate version using TM_END / TM_JOIN was put in place instead to notify the resource and potentially enable transaction interleaving.
Looking back, it probably was a mistake as almost no resource implements transaction interleaving and this simpler model fits the bill for the more common transaction-per-connection model.
Suspend/resume serve no other purpose than enabling the requires_new and not_supported transaction boundaries. While it has other theoretical purposes like enabling nested transactions, BTM does not support that as it's practically useless in the field.
I'm rather curious about your 'the current implementation feels weighty' comment. Have you made some performance measurements? Against what DB?
If you add some decent test coverage for the feature, you have my blessing for having this feature in.
That's good to hear, i'll add in some test coverage and update the pull-request.
Your explanation also answers my other question, about why btm uses TM_END on the suspend call - that's good to know.
On my 'weighty' comment; that wasn't based on an observed performance issue, but rather just on the relative cost of communicating with each resource for suspend compared to the 'quick' (local-state-only) approach.
Updated with good unittest support. All tests are passing - feels good to go. Let me know what you think.
@lorban i realized that this has been sitting for a bit of time. Do you have any thoughts on my comment above? How do we proceed?