Question about using virtual thread

[刘希晨]

Hi I have several questions about using virtual threads in web application:

1. When using per-request-per-virtual-thread style programming model, a
general case would be to acquire a jdbc connection from some database
connection pool, launch a SQL request, and then release the connection. I
have some doubts that since database connections are usually a small
number(like at most 100 connections), most of the virtual threads are
waiting for them if requests come in quite fast. In this case, should I
limit the number of virtual threads to reduce unnecessary waiting?

2. Is it recommended to create like several thousands of virtual threads,
waiting to perform take() from a BlockingQueue infinitely? I noticed
pooling virtual threads is definitely not recommended, so I am a
little confused about this idea. which really sounds like pooling, but this
mechanism can control the virtual threads concurrency pretty easily.

3. Sometimes a request may needs to perform a SQL request, sometimes not. I
am wondering whether I should put the acquired database connection in a
ThreadLocal or a ScopedValue. In old times, ThreadLocal would be perfect
for this senario, however it seems that ScopedValue are preferred to be
used in virtual threads. I noticed that the object that ScopedValue holds
should remain unchanged during the method, but the unchanged object could
have changable fields. So if when I receive a Http request, I create a
object with a database connection field initialized as null, then when it
needs to perform a SQL request, acquire a database connection and then put
it into the ScopedValue's object, thus the later actions could all find it
and use it from the ScopedValue.
I don't know if it's recommended to use ScopedValue like this, which really
looks like ThreadLocal.

Please correct me if I am wrong, Thank you guys for your great work making
Java better !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230612/b5d88ec2/attachment.htm>