-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Move setDefaultProperties in the static init #40250
Conversation
/cc @mmusgrov |
Status for workflow
|
@@ -137,6 +138,16 @@ public void build(NarayanaJtaRecorder recorder, | |||
builder.addBeanClass(TransactionalInterceptorNotSupported.class); | |||
additionalBeans.produce(builder.build()); | |||
|
|||
// This must be done before setNodeName as the code in setNodeName will create a TSM based on the value of this property | |||
recorder.disableTransactionStatusManager(); | |||
recorder.setNodeName(transactions); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did someone check if we end up having the same node names across all instances?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think Amos actually changed these lines, the diff is showing because the other lines were reordered. I believe that the only change is to move the code that sets up the defaultProperties into a @record(STATIC_INIT) build step (he added the new method public void setProperties(NarayanaJtaRecorder recorder)
. Is that correct @zhfeng ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it is. Thanks @mmusgrov !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Sanne I don't understand here. What are you mean all intances?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "instances" I mean instances of the application. If I start 10 copies of the same Quarkus application, it's my understanding that it's essential that they are assigned a different Node Name - or at least to offer the possibility of users to configure different node names.
By seeing the setNodeName
invoked on a build-time recorder, it makes me worry that this configuration setting wouldn't be honoured at runtime: I'm suggesting to please check this as it would be a grave mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, no, setNodeName
is at runtime. And this commit has been reverted in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a much more insightful fix than the ones suggested on the issue, I approve.
Should we backport this too? |
@gastaldi yeah, at least for |
@@ -145,11 +156,6 @@ public void build(NarayanaJtaRecorder recorder, | |||
defaultProperties.remove(i); | |||
} | |||
recorder.setDefaultProperties(defaultProperties); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this, in the case of a native executable, the properties will be set at build time. This is what you want for all of them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point - @mmusgrov do know if there is any property we don't want to set at build time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we only expect to apply these properties at run time. It has to revert this commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure but it seems restrictive, Narayana has many useful configuration options which were added to give users runtime control over how the TM operates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I open #40310 and it looks good to make BeanPopulator
to init at runtime. So we don't need any change on narayana side.
This comment of mine here is worrying me, did someone check it? |
This change was reverted in #40334 . |
It related to
SQLException: Unable to enlist connection to existing transaction
when accessing multiple persistence units in the same transaction since 3.8.2 #39283