Question about using virtual thread

[Holo The Sage Wolf]

**** The first sentence should have mean that you shouldn't use *virtual
threads* in CPU heavy applications, not that CPU heavy applications should
pool virtual threads.

You should *never* pool virtual threads

On Mon, Jun 12, 2023, 19:51 Holo The Sage Wolf <holo3146 at gmail.com> wrote:

> 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/71b000b4/attachment-0001.htm>