Hi,

On Thu, Mar 19, 2015 at 8:52 PM, Jens Schumann <jens.schumann@openknowledge.de> wrote:
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).

Practically, maybe... it depends. @ApplicationScoped is a different thing too. Everything it contains is shared with all callers, while for @Stateless beans every caller gets its own instance.
 
Most @Stateless EJBs are implemented thread-safe unless someone violated
the Stateless EJB contract;).

An @Stateless bean does not have to be thread-safe, since the stateless contract guarantees only one thread is ever active in a bean. I explained this into some more detail here: http://en.wikipedia.org/wiki/Enterprise_JavaBeans#Stateless_Session_Beans

One pattern of using stateless beans is to inject or instantiate a non-thread safe resource in the @PostConstruct method, and then be assured that only 1 thread ever accesses that resource at the same time without paying for any locking overhead (such as in @Singleton beans).

If the resource is heavyweight to create, you would usually depend on stateless beans being pooled, but unfortunately this is a container specific feature.

Kind regards,
Arjan Tijms

 

Jens

Am 19/03/15 20:34 schrieb "Mark Struberg" unter <struberg@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@gmail.com>:
>>
>> Hi
>>
>> On Thursday, March 19, 2015, Mark Struberg <struberg@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@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@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.