Question about using virtual thread

[Bazlur Rahman]

The questions and answers are interesting, and I wanted to know if I could
turn it into an article.

*Thank you,*
*-*
*A N M Bazlur Rahman*

---
*"And say: 'My Lord, increase me in knowledge.'" - Quran 20:114.*

*Java Champion*
*Software Engineer*
JUG Leader, JUGBD.org
<https://mailtrack.io/trace/link/c1910ddf221eeaaab33f7b0c3b4a59f07ce2d850?url=http%3A%2F%2FJUGBD.org&userId=2428395&signature=1107914e538ec467>
Java Queue Editor, InfoQ
<https://mailtrack.io/trace/link/405e826e319d45a9eefc4bdff3a9b721b03338e1?url=https%3A%2F%2Fwww.infoq.com%2Fprofile%2FA-N-M-Bazlur-Rahman%2F&userId=2428395&signature=c61665d2fac02d91>
Editor at Foojay.io
<https://mailtrack.io/trace/link/540a2d8d81335de19844fa82bfc8ee57b2a52677?url=https%3A%2F%2Ffoojay.io%2Ftoday%2Fauthor%2Fbazlur-rahman%2F&userId=2428395&signature=37520cbf685951c0>
About Me
<https://mailtrack.io/trace/link/9e3489b331a5a2eb593ef05641d00c0758dd6478?url=https%3A%2F%2Fbazlur.ca%2Fabout%2F&userId=2428395&signature=52298980285b09f2>
https://bazlur.ca/
<https://mailtrack.io/trace/link/a58fdff0019c7adf8ad8b001ada40933217b04da?url=https%3A%2F%2Fbazlur.ca%2F&userId=2428395&signature=78f5484a7a6b8f36>


On Mon, Jun 12, 2023 at 3:18 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 12 Jun 2023, at 11: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?
>
> No, you should not. When a thread blocks waiting for something, behind the
> scenes you get the exact same queue you’d get if you tried to throttle
> manually, only easier to use. So just block and wait — that’s what virtual
> threads do best. Of course, depending on what percentage of the threads
> actually need to access the database (as opposed to getting their data from
> a cache) the database may become your bottleneck.
>
> >
> > 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.
>
> It’s impossible to create more or less virtual threads than you need.
> Every concurrent task in your application is represented by a virtual
> thread. It’s not that pooling virtual threads is not recommended, it’s that
> it cannot possibly ever improve anything, and it could make things work.
> You never, ever, pool virtual threads. EVER.
>
> >
> > 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.
> >
>
> Use whichever one you prefer. ScopedValues are not preferred for virtual
> threads; they’re preferred *always* in situations where their structured
> use fits their purpose. I wonder, though, why do you want to store the
> connection in the thread anyway. If you’re using a connection pool, you can
> just give it back and request again if you need to. If you do need to hold
> onto a connection for some reason, you probably need to close it or return
> it to the pool, so it sounds like somewhere in your thread you know when
> you’re done, which suggests that structured use would be possible, and if
> it’s possible — it’s preferable.
>
> — Ron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230612/b9066c3a/attachment-0001.htm>