<div dir="ltr">I wrote some tests for connection pools and JDBC drivers [1]. However, currently I have added only a limited number of options (H2, Postgres with loom-aware driver, Postgres with old driver) and DBCP2 for connection pool with the addition of semaphore based "connection pool". Also, I haven't yet run the tests for all combinations (since it takes a lot of time), but I have at least verified that DBCP2 does improve with virtual threads compared to if it completely pinned a thread.<div><br></div><div>The current setup is the following:</div><div><br></div><div>- Starts 2 * CPU times the following submit chains: "CPU action -> Connection action -> CPU action -> Connection action". These 4 steps are consecutive submits trying to deal with the unfairness of Loom.</div><div><br></div><div>- We have two ways to fork new tasks: One is to simply start a virtual thread, the other tries to simulate carrier thread pinning by using an executor: `Executors.newFixedThreadPool(CPU_COUNT)`</div><div><br></div><div>- Both for the "CPU action" and "Connection action" it is possible to sleep instead, because a problem I run into is that it is sometimes hard to detect the adverse effect of thread pinning, because if the DB is running on the same machine as the test, then it won't matter much, since the DB will make your CPU busy anyway.</div><div><br></div><div>While doing this I have noticed one thing however: H2 is very loom unfriendly, because it is full of `synchronized`. The worst part is that at some places they even documented that you can externally synchronize via a synchronized block, meaning that if they are to fix everything, that will be - in theory - a breaking change for H2. That said, I can't imagine somebody using the same `PreparedStatement` and similar objects concurrently. I'm in the process of trying to create a version of H2 from which I remove all the synchronized blocks, but it takes quite a bit of time.</div><div><br></div><div>Anyway, any tests, comments and improvements are welcome.</div><div><br></div><div>[1]: <a href="https://github.com/kelemen/loom-db-test">https://github.com/kelemen/loom-db-test</a></div><div><br></div><div>Attila</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> ezt írta (időpont: 2023. jún. 15., Cs, 17:22):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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><br>
    It's possible this topic will come up many times. I wonder if anyone
    with experience in this area would have time to do an inventory of
    the JDBC drivers and the DB connection pools to see how they behave
    with virtual threads.  Oracle's JDBC driver, PostgreSQL JDBC driver,
    and a few others have JDBC drivers that work well with virtual
    threads but I have seen much on DB connection libraries. Do they
    provide API that wait for a connection to be available without
    pinning a virtual thread?<br><br></div></blockquote><div><br></div><div>To be honest, I haven't actually tested with virtual threads, but dbcp2 relies on Apache Commons Pool2 which uses `GenericObjectPool` [1] for pooling which uses `LinkedBlockingDeque` itself (no synchronized blocks or native shenanigans), so I would expect it work well with Loom. Anyway, I can write some tests on how well behaved these pools (with various configurations) with Loom on the weekend.</div><div><br></div><div>[1]: <a href="https://github.com/apache/commons-pool/blob/rel/commons-pool-2.11.1/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java" target="_blank">https://github.com/apache/commons-pool/blob/rel/commons-pool-2.11.1/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java</a></div><div> </div></div></div>
</blockquote></div>