[cdi-dev] Enhancing SPI to support async operation for contexts

[Romain Manni-Bucau]

@Mark: for the container usage only but nothing prevents you to use it
elsewhere at your own risk


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-02-19 17:40 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
> Even in Servlets-3.0 a ‚Request‘ is only attached to exactly one single thread AT THE SAME TIME afaik.
>
> So they can switch a Request from one thread to another one, but there is always just a single one accessing it at the same time. At least that is what I did understand.
>
> LieGrue,
> strub
>
>
>> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt <sven.linstaedt at gmail.com>:
>>
>> Hi,
>>
>> and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions:
>>
>> 1. Regarding threading the current spec only states that "A context may be associated with one or more threads".
>>
>> 2. It is nowhere stated that @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded.
>>
>> 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via  ServletRequest#startAsync(), so containing objects may have a need for synchronization.
>>
>> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe.
>>
>>
>> Best regards
>> Sven
>>
>> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>> Hi
>>
>> I'm +1 for it but it needs important changes (= surely new contexts).
>> Typically we can't change today @RequestScoped (which has no link with
>> a request but only with a thread!).
>>
>> So we could have @RequestScoped (~ @ThreadLocalScoped) and
>> @InheritedRequestScoped which would be a real request scope (but not
>> an InheritedThreadLocal please)
>>
>> For the request it makes a lot of sense since you need to stay thread
>> safe even accross threads (servlet spec) and avoids to be forced to
>> use message passing which - even if a good pattern - adds boilerplate
>> code for simple async needs.
>>
>> For JAXRS I dont know since it is really suspend/resume semantic so
>> request scope maybe doesnt makes much sense here (there is a break in
>> the flow).
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>> > Hi All,
>> >
>> > Beyond the asynchronous event case, shouldn’t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch?
>> > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn’t we think to something like that?
>> >
>> > Thanks for your input on that point.
>> >
>> > Antoine
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > cdi-dev at 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.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.