High Contention due to inroduced call to DriverManager.println

[yuvalp-k2view]

Describe the bug
NativeDB_exec and NativeDB.prepare() call DriverManager.println()
Unfortunately this method has a global lock creating a huge bottleneck in multithread (connection per thread) environments.
I suggest removing these calls.

To Reproduce
Prepare statements on multiple threads

Expected behavior
No contention between threads working on separate connections.

Additional context
println imp for your reference :-(

public static void println(String message) {
    synchronized (logSync) {
        if (logWriter != null) {
            logWriter.println(message);

            // automatic flushing is never enabled, so we must do it ourselves
            logWriter.flush();
        }
    }
}

[gotson]

Unfortunately this method has a global lock creating a huge bottleneck in multithread (connection per thread) environments.

Would you be able to share more on this?

[gotson]

Related to #802

[yuvalp-k2view]

I've attached the code from DriverManager. You see that they are synchronizing logSync which is defined:
private static final Object logSync = new Object();

This means that even if there is no logging, there is a contention point that all threads creating a prepared statement go through. I think this method should be avoided, especially in success scenarios where high throughput is required.

[gotson]

Yes I saw that, but did you do some tests or benchmarks with and without? Or is that just an observation of the code above and that's it?

[yuvalp-k2view]

This came up in real life. The complaint was we could not scale vertically on a larger machine (128 vcpu).
We could not go beyond 20% cpu usage. Once we identified that our threads were mostly blocked, I found this. Downgrading the version resolved the issue and our threads were no longer blocked.

[gotson]

Thanks, that is useful context that could have been provided in the first post.

[github-actions]

🎉 This issue has been resolved in 3.43.2.0 (Release Notes)