12:01 p.m.
From the servlet spec:
„Java Enterprise Edition features such as Section 15.2.2, “Web Application Environment” on
page 15-174 and Section 15.3.1, “Propagation of Security Identity in EJBTM Calls” on page
15-176 are available only to threads executing the initial request or when the request is
dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition
features may be available to other threads operating directly on the response object via
the AsyncContext.start(Runnable) method.“
check „available only to threads executing the initial request“
Also if you look at the servlet AsyncContext then all the wording is written as MAY and
not as MUST.
LieGrue,
strub
Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau
<rmannibucau(a)gmail.com>:
Hi Mark,
think 2.3.3.4 states the opposite.
Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber
2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de>:
Back from JavaLand conference, so sorry for not kicking in earlier.
I not quite get the argumentation chain. It’s that all triggered by async servlet
requests? And isn’t the servlet spec also saying that all the request param etc may max be
assigned to a single thread AT A TIME!
Means that it might not be on multiple threads in parallel, but the data is allowed to
get moved from one thread to another (disapearing from the first one), right?
Would really need to dig into the wording of the async servlets spec again, maybe has
this in the back of his head?
LieGrue,
strub
> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com>:
>
> Hi guys,
>
> following request scope thread and to center the discussion on the thread safety
part: do we work on this?
>
> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot
of SE or Batch implementations rely on it from what I saw as well as async implementations
reusing existing business logic with this thread safety constraint.
>
> Proposal: providing a @ThreadScoped implementation is cheap for CDI and
implemenation and would avoid the headache we can have with @RequestScoped. Will also
remove the quite dark side of the spec regarding servlet request and request scope since
now we would have a more natural solution for all of these situation so @RequestScoped
goals wouldn't collide as much.
>
> Questions:
> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative
could be some configuration in beans.xml (merged accross the app):
>
> <beans>
> <scopes>
> <thread>
> <active>JMS</active>
> <active>ASYNCHONOUS</active>
> </thread>
> </scopes>
> </beans>
>
> - start/stop API (this is typically an API the user should be able to control for
its own threads)
> - CDI 2.*0*?
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.