Servlet 3.0 - Section 2.3.3.3. " When asyncSupported is set to true the application can start asynchronous processing in a separate thread by calling startAsync , passing it a reference to the request and response objects, and then exit from the container on the original thread. This means that the response will traverse (in reverse order) the same filters (or filter chain) that were traversed on the way in. The response isn't committed till complete is called on the AsyncContext.
*The application is responsible to handle concurrent access to the request and response objects if the async task is executing before the container-initiated dispatch that called startAsync has returned to the container.* " This mean parent and async task/s may be executing concurrently. cheers, --Rohit On Fri, Jun 22, 2012 at 5:21 PM, Mark Struberg <strub...@yahoo.de> wrote: > > > My understanding of this is that there is still only 1 concurrent Thread. > The 'request' will will just get moved over to a new worker, but still max > 1 at a time, isn't? > > But have only read over the spec quickly, will need to dig much deeper... > > LieGrue, > strub > > > > > >________________________________ > > From: Rohit Kelapure <kelap...@gmail.com> > >To: dev@openwebbeans.apache.org; Mark Struberg <strub...@yahoo.de> > >Sent: Friday, June 22, 2012 11:12 PM > >Subject: Re: CDI context propagation for threads spawned asynchronously > using servlet 3.0 and javax.resource.spi.work.WorkManager APIs > > > > > > > >Team, > > > > > >Does it make sense to propagate the RequestContext ? given that there > may be multiple threads that will inherit and share the same RequestContext > > > > > >We will need to manage the destruction of the RequestContext such that > only the last one (Parent + child async threads) ends the context. > > > > > >This could get messy with locking and keeping track of when each runnable > exits. For servlet 3.0 this may not be a problem since the AsyncListener > will abstract all this for us. Unfortunately there is no good place to add > the per request listener asynclistener. > > > > > >The basic issue here is that sharing of the RequestContext leads to > complexity in ending the context. > > > > > >-cheers, > >Rohit > > > > > >On Fri, Jun 22, 2012 at 12:36 PM, Mark Struberg <strub...@yahoo.de> > wrote: > > > > > >> > >>Hi folks! > >> > >>We are aware that OWB currently doesn't provide this. But all the > information is already centrally collected and maintained in the > ContextsService. > >>For WAS this will most probably be the WebContextsService. So all you > need to know is centrally available there. > >> > >>Also the TheadLocal caches in the proxies will need to get cleared (if > being used). > >> > >>In practice this doesn't make any problems atm, as asynchronous requests > must only get performed if ALL involved Servlets, Filters, etc must have > >> > >><async-supported>true</async-supported> > >> > >> > >>Of course, at the end of the day we should support it! > >> > >>Will take a look once I'm back from the conference next week. > >> > >> > >>LieGrue, > >>strub > >> > >> > >>----- Original Message ----- > >>> From: Romain Manni-Bucau <rmannibu...@gmail.com> > >>> To: dev@openwebbeans.apache.org > >>> Cc: > >>> Sent: Friday, June 22, 2012 6:24 PM > >>> Subject: Re: CDI context propagation for threads spawned > asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager > APIs > >>> > >>> Hi, > >>> > >>> i don't know any standard way but what i often saw was to create a > kind of > >>> "invocation context" to avoid to need anything in the async call. > >>> > >>> - Romain > >>> > >>> > >>> 2012/6/22 Rohit Kelapure <kelap...@gmail.com> > >>> > >>>> Team, > >>>> > >>>> Do we have a standard way of propagating CDI contexts (request, > session, > >>>> application, singleton, conversation) and other threadlocal state > from a > >>>> parent thread say servicing a servlet request to its dispatched child > >>>> runnable using the servlet 3.0 AsyncContext.startAsync or the > WorkManager > >>>> APIs. > >>>> > >>>> I understand that the solution may be specific to individual > containers > >>>> like Tomcat, WebLogic, WAS etc ... > >>>> Has anyone already solved this problem for their container ? > >>>> Thought I would ask before fixing it in WAS. > >>>> > >>>> -cheers, > >>>> Rohit Kelapure > >>>> > >>> > >> > > > > > > >
