So it sort of looks like a DSL for a variant of ThreadLocal that gives you an idea of the lifeline of variable instead of just being global. Apparently with virtual threads they are expecting an increase in the number of running (virtual) threads several orders of magnitude larger than what was previously seen and that with ThreadLocals would just be too much.
Which stores the object referenced by `context` to the ScopedValue container `CONTEXT` ^ for the duration of the thread running `Application.handle(request,response)`.
Not really sexy, but I understand how you might really benefit if you are processing lots of data, but for most enterprise CRUD apps this seems inapplicable.
^ I think this a "monad"? I'm not a functional programmer.
The problem with thread locals is that you need to copy the value into each platform thread. And the expectation of virtual threads is that any platform thread from the pool would end up running them.
This is super applicable to any system, enterprise or not. If the web framework is running on virtual threads as soon as you query the database your virtual thread will be parked and then another platform thread could potentially pick it up finish running it. Managing thread locals in this situation would be impossible, but you still need some mechanism to manage the global context. It’s really nothing to do with data volume.
ThreadLocal in Java understands the new lightweight "virtual" threads. If you write into a ThreadLocal, when you read it out on the same virtual thread (even if it's scheduled to a different platform thread) you'll get the same value back.
Implicit parameter smuggling by any mechanism is just too much magic in my experience. Golang's context.Context solves the same problem, but explicitly in a way that has been widely adopted through their language ecosystem.
That said - in Java I do think it would be near impossible for the ecosystem to adopt a similar mechanic, so from a practical standpoint this may be the only way to reliably propagate context.
I think it is due to java already featured the threadlocal mechanism so the ecosystem get used to it. I just recently rediscovering java (w/o framework) when virtual thread landed and I gravitated towards context passing. Even more recently I started reading golang code only to then seeing they were doing the same thing.
Readit News
So the have added this:
> ScopedVaule.where(CONTEXT, context).run(() -> Application.handle(request, response));
Which stores the object referenced by `context` to the ScopedValue container `CONTEXT` ^ for the duration of the thread running `Application.handle(request,response)`.
Not really sexy, but I understand how you might really benefit if you are processing lots of data, but for most enterprise CRUD apps this seems inapplicable.
^ I think this a "monad"? I'm not a functional programmer.
This is super applicable to any system, enterprise or not. If the web framework is running on virtual threads as soon as you query the database your virtual thread will be parked and then another platform thread could potentially pick it up finish running it. Managing thread locals in this situation would be impossible, but you still need some mechanism to manage the global context. It’s really nothing to do with data volume.
So it's applicable to those writing the framework, not those using it.
That said - in Java I do think it would be near impossible for the ecosystem to adopt a similar mechanic, so from a practical standpoint this may be the only way to reliably propagate context.
I see value in this proposal