Skip to content
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

Use xaresource tmsuspend when suspending instead of tmsuccess #23

Open
wants to merge 3 commits into
base: support/2.1.x
Choose a base branch
from

Conversation

ca-stefan-cordes
Copy link

The XAResourceHolderState.suspend did not call .end(XAResource.TMSUSPEND);
but .end(XAResource.TMSUCCESS); and so a compicated re-join needed to be implemented on .resume()

Just calling
.end(XAResource.TMSUSPEND);
on suspend and
.start(XAResource.TMRESUME);
on resume ensures all resources keeping same and XA provider is not wondering why TMSUSPEND is never called:

IBM asked me:

Would we be right in our understanding that in this context, the application is enlisting MQ in a XA transaction, doing a piece of MQ work (eg. getting a message from a queue), then suspending the transaction, eg:
XAResource.end( Xid xid, int flags )
passing the TMSUSPEND flag as the flags argument, then doing the new piece of transacted work with the database, before attempting to resume the transaction with:
XAResource.start( Xid xid, int flags )
passing the TMRESUME flag to the queue manager?

and I need to answer: "Well .... you know .... looks like .... hmmm..."

P.S.: Probably not all tests green now as mvn clean test alreads showed errors locally on my environment.

Suspend should just TMSUSPEND the transaction and resume just TMRESUME
…SUCCESS TMJOIN

Suspend should just TMSUSPEND the transaction and resume just TMRESUME
…tion

See bitronix.tm.JtaTest.testRecycleAfterSuspend()
(alternative maybe to disable the test as "{@link XAResource#TMSUSPEND} and {@link XAResource#TMRESUME} are not supported.")
@ca-stefan-cordes
Copy link
Author

The request to use suspend/resume directly was already made on the original repository with scalar-labs#40
@lorban already stated 2015 that

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.

and so today is a good day to switch the default to the lightweight suspend/resume.

In case you want to be able to keep old behavior via

I can cherry pick the (open) commit
TransactionManagerServices.getConfiguration().isQuickSuspend()
from
scalar-labs@ce7ed4b
here, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant