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

Loom friendly synchronization. #1931

Merged
merged 6 commits into from
Oct 25, 2022
Merged

Conversation

jono-coder
Copy link
Contributor

See: #1154

Replaced the traditional "synchronized(foo)" with Reentrant locks as Loom, which is a preview feature in jdk-19, "breathes" more easily with a Lock which can be parked, and performance is increased.

@jono-coder
Copy link
Contributor Author

jono-coder commented Oct 5, 2022 via email

@jono-coder
Copy link
Contributor Author

jono-coder commented Oct 5, 2022 via email

1 similar comment
@jono-coder
Copy link
Contributor Author

jono-coder commented Oct 5, 2022 via email

@Jeffery-Wasty
Copy link
Member

@jono-coder

Not sure what's going on with the bot here, can you try replying with @microsoft-github-policy-service agree company="" instead?

cogman
cogman previously approved these changes Oct 5, 2022
Copy link
Contributor

@cogman cogman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you found a bunch of great cases in here. Great work!

@@ -3150,6 +3174,7 @@ final class SocketConnector implements Runnable {
// a counter used to give unique IDs to each connector thread.
// this will have the id of the thread that was last created.
private static long lastThreadID = 0;
private static final Lock LOCK = new ReentrantLock();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could probably all be replaced and simplified with an AtomicLong

}
return lastThreadID;
} finally {
LOCK.unlock();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of this could be tidied up with AtomicLong#updateAndGet

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I did this in another commit.

@David-Engel
Copy link
Contributor

Judging by the timeframes, it looks like the CLA bot might have been affected by a GitHub service issue:
https://github.com/microsoft/GitOps/issues/703

I'd try replying to the bot once more and see if it works now. After that, I'd try closing and re-opening this issue (close/re-open button - don't need to re-create the PR) and see if the license/cla integration gets reset and replying starts working.

@jono-coder
Copy link
Contributor Author

jono-coder commented Oct 6, 2022 via email

@jono-coder
Copy link
Contributor Author

jono-coder commented Oct 11, 2022 via email

import com.microsoft.sqlserver.jdbc.dataclassification.SensitivityClassification;

import javax.net.SocketFactory;
import javax.net.ssl.*;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a convention with the driver project, correct all wildcard imports back to explicit imports.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

tkyc
tkyc previously approved these changes Oct 13, 2022
public Iterator<Entry<Integer, Object[]>> getIterator() {
lock.lock();
try {
if (null != rows) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the check for rows.entrySet() not equal to null removed here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change probably "came out in the wash". It's a redundant check as rows.entrySet() can never be null.

if (null == importedKeysDWColumns) {
LOCK.lock();
try {
importedKeysDWColumns = getImportedKeysDWColumns;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use another variable importedKeysDWColumns instead of getImportedKeysDWColumns directly. I understand both are variable, and that explains why you check for null before and after locking but can't that be done without the use of a middleman variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's not technically incorrect, but this is using double-checked locking (using a volatile). Perhaps you don't like the idiom?

boolean hasColumnEncryptionKeyStoreProvidersRegistered() {
lock.lock();
try {
return null != statementColumnEncryptionKeyStoreProviders && statementColumnEncryptionKeyStoreProviders.size() > 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't exceed line length (80 chars)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll commit a change.


/**
* physical connection
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be a single line comment like line 39 below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll commit a revert.

if (instance == null) {
// No shared object exists so create a new one
instance = new SharedTimer();
SharedTimer result = instance;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: I understand why the double null check now, why is result being used instead of looking at instance directly?

Similar comment to above, why can't this just be wrapped in a try / catch like the other changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refer to https://en.wikipedia.org/wiki/Double-checked_locking

"Note the local variable "localRef", which seems unnecessary. The effect of this is that in cases where helper is already initialized (i.e., most of the time), the volatile field is only accessed once (due to "return localRef;" instead of "return helper;"), which can improve the method's overall performance by as much as 40 percent."

One could use the VarHandles stuff for even better performance but that's even trickier.

if (XAResource == null)
XAResource = new SQLServerXAResource(getPhysicalConnection(), physicalControlConnection, toString());
return XAResource;
SQLServerXAResource result = XAResource;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: I understand why the double null check now, why is result being used instead of looking at XAResource directly?

Similar to above, why can't this just be wrapped in a try / catch block like the other changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refer to https://en.wikipedia.org/wiki/Double-checked_locking

"Note the local variable "localRef", which seems unnecessary. The effect of this is that in cases where helper is already initialized (i.e., most of the time), the volatile field is only accessed once (due to "return localRef;" instead of "return helper;"), which can improve the method's overall performance by as much as 40 percent."

One could use the VarHandles stuff for even better performance but that's even trickier.

@lilgreenbird lilgreenbird added this to the 12.1.0 milestone Oct 20, 2022
@Jeffery-Wasty Jeffery-Wasty merged commit bf7adc0 into microsoft:main Oct 25, 2022
MSSQL JDBC automation moved this from Under Peer Review to Closed/Merged PRs Oct 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
MSSQL JDBC
  
Closed/Merged PRs
Development

Successfully merging this pull request may close these issues.

None yet

6 participants