Question about using virtual thread

[Rob Bygrave]

*> why do you want to store the connection in the thread [local] anyway*

This is done today where we see methods annotated with `@Transactional.
That is, these methods initiate the beginning of the transaction acquiring
a connection [from a DataSource pool], the connection/transaction is put
into a ThreadLocal and is then accessible to code during the method
execution that needs/uses the transaction, and finally at the end of the
method scope the transaction is completed/ended including a call to the
underlying connection.commit() or connection.rollback() plus ensuring the
connection/transaction is removed from the ThreadLocal.

NB: I say the ThreadLocal has a connection/transaction because typically
it's not going to hold s java.sql.Connection directly per se but instead a
type that wraps a java.sql.Connection and deals with some details like
nested transactions (savepoints) etc.

If you see code today that has a method annotated with `@Transactional`,
then you are almost guaranteed that it will be using a ThreadLocal under
the hood to hold a "transaction" that in turn holds a  java.sql.Connection.

Cheers, Rob.

On Tue, 13 Jun 2023 at 08:15, Bazlur Rahman <anmbrr.bit0112 at gmail.com>
wrote:

>
> 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/20230613/4849e04d/attachment.htm>