<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br>To detect thread pinning, you might try:</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><code>-Djdk.tracePinnedThreads=full</code></div>
</blockquote>
<div><font face="monospace"><br>
</font></div>
<div><span>This system property is documented in JEP 444:</span><span></span></div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span>The system property jdk.tracePinnedThreads triggers a stack trace when a thread blocks while pinned. Running with -Djdk.tracePinnedThreads=full prints a complete stack trace when a thread
 blocks while pinned, highlighting native frames and frames holding monitors. Running with -Djdk.tracePinnedThreads=short limits the output to just the problematic frames.</span></blockquote>
<span>
<div><a href="https://openjdk.org/jeps/444#Executing-virtual-threads" target="_blank">https://openjdk.org/jeps/444#Executing-virtual-threads</a></div>
<div><br></div></span></div></blockquote><div><br></div>Thanks, this system property eluded me for some reason. Anyway, I have checked the DB pools by enabling it, and they - with the exception of DBCP2 - don't report any pinning. Even DBCP2 only uses `synchronized` when returning the connection to the pool (seems trivially fixable in DBCP2).<div><br></div><div>I have tried to check the Derby anomaly with it, but still a bit puzzled, because it indeed seems to pin the thread always on `executeStatement`. There is some trickery there with potentially using the same lock for multiple connections, but I don't see why that would happen. That said, I didn't read its code that thoroughly. </div></div></div>