Question about using virtual thread

[Holo The Sage Wolf]

You shouldn't pool virtual threads at all if you don't do CPU heavy
processing, the most you do is limit the number of live virtual threads.

Pooling means you re-use the same instances, but when you use a virtual
thread you should forget about it after it is done, and create an entirely
different virtual thread for the next task. To limit the amount of virtual
threads you can use semaphores for this (still using a newThreadPerTask
-like executor).

You should create a single thread that infinitely run, receive an element
(from jbdc/queue/...) And fork a new task for this new element, see the
"fan-in" example in Structured Concurrency [1].

About the last point, I would recommend creating an object that handle the
connections and hides a ScopedValue.

Unrelatedly to the question itself, it is almost never a good practice to
have a non-private threadLocals/ScopedValues.



[1] https://openjdk.org/jeps/453

On Mon, Jun 12, 2023, 18:39 刘希晨 <benrush0705 at gmail.com> wrote:

> 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/1d6bbeb3/attachment.htm>