Question about using virtual thread

[Attila Kelemen]

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.

The current setup is the following:

- 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.

- 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)`

- 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.

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.

Anyway, any tests, comments and improvements are welcome.

[1]: https://github.com/kelemen/loom-db-test

Attila


Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2023. jún.
15., Cs, 17:22):

>
>> 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?
>>
>>
> 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.
>
> [1]:
> https://github.com/apache/commons-pool/blob/rel/commons-pool-2.11.1/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230619/db597716/attachment.htm>