[cdi-dev] On @Observes for async events

[Jens Schumann]

Mark,

Are you sure with that?

I agree with you if you look from a implementation point of view. However
I believe that most @Stateless EJBs can easily be migrated to
@ApplicationScoped. (At least this is what we have been doing in our
migration projects until now).

Most @Stateless EJBs are implemented thread-safe unless someone violated
the Stateless EJB contract;).

Jens

Am 19/03/15 20:34 schrieb "Mark Struberg" unter <struberg at yahoo.de>:

>> Slightly off topic perhaps, but @Stateless is difficult to map to a
>>(CDI) scope. Everytime a method is called on a proxy, a different actual
>>bean instance can be used
>
>That is EXACTLY as NormalScoped beans are handled. Just think of
>@Stateless as a @PoolScoped CDI bean. And then you are almost there…
>
>It’s basically @RequestScoped with re-using instances by putting them
>back into a poll cache (like we had it with JSP tags in the old days).
>And of course with a few default Interceptors. But that’s really it.
>
>LieGrue,
>strub
>
>
>> Am 19.03.2015 um 19:14 schrieb arjan tijms <arjan.tijms at gmail.com>:
>> 
>> Hi
>> 
>> On Thursday, March 19, 2015, Mark Struberg <struberg at yahoo.de> wrote:
>> >> but opposed to ee concurrency utilities
>> >
>> > I thought this was by mistake rather than design?
>> 
>> 
>> 
>> As far as I remember there was a long discussion on the EJB EG and it
>>was intentionally that @Asynchronous does NOT propagate any information
>>about the session, security, and don’t even share the same pool instance
>>from @Stateless (pool ~what we have as @RequestScoped).
>> 
>> Slightly off topic perhaps, but @Stateless is difficult to map to a
>>(CDI) scope. Everytime a method is called on a proxy, a different actual
>>bean instance can be used (but it can also be the same bean instance as
>>used for the previous call from the same thread)
>> 
>> The concept is actually not that far removed from a message passing
>>paradigm, but using synchronous communication and a typed target.
>> 
>> Kind regards,
>> Arjan Tijms
>> 
>>  
>> 
>> The reason is that EJB is all about removing concurrency complexity
>>from the user as good as possible. The other problem is that you don’t
>>have it under control how long the new thread will run. And the Session
>>might be looong time dead already. Another issue is with TX handling.
>>The JPA spec and also JTA spec (TransactionSynchronizationRegistry)
>>defines that a transaction must not be used ‚concurrently‘. Means they
>>only must be assigned to a very single Thread.
>> 
>> Even with servlet 3.0 async requests you have a ServletRequest only
>>attached to a very single thread AT EACH TIME (means the thread might
>>switch, but it’s max 1 at a time).
>> 
>> 
>> 
>> LieGrue,
>> strub
>> _______________________________________________
>> 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.