<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 8:52 PM, Jens Schumann <span dir="ltr"><<a href="mailto:jens.schumann@openknowledge.de" target="_blank">jens.schumann@openknowledge.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I agree with you if you look from a implementation point of view. However<br>
I believe that most @Stateless EJBs can easily be migrated to<br>
@ApplicationScoped. (At least this is what we have been doing in our<br>
migration projects until now).<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Most @Stateless EJBs are implemented thread-safe unless someone violated<br>
the Stateless EJB contract;).<br></blockquote><div><br></div><div>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: <a href="http://en.wikipedia.org/wiki/Enterprise_JavaBeans#Stateless_Session_Beans">http://en.wikipedia.org/wiki/Enterprise_JavaBeans#Stateless_Session_Beans</a></div><div><br></div><div>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).</div><div><br></div><div>If the resource is heavyweight to create, you would usually depend on stateless beans being pooled, but unfortunately this is a container specific feature.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Jens<br>
<br>
Am 19/03/15 20:34 schrieb "Mark Struberg" unter <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>:<br>
<div class=""><div class="h5"><br>
>> Slightly off topic perhaps, but @Stateless is difficult to map to a<br>
>>(CDI) scope. Everytime a method is called on a proxy, a different actual<br>
>>bean instance can be used<br>
><br>
>That is EXACTLY as NormalScoped beans are handled. Just think of<br>
>@Stateless as a @PoolScoped CDI bean. And then you are almost there…<br>
><br>
>It’s basically @RequestScoped with re-using instances by putting them<br>
>back into a poll cache (like we had it with JSP tags in the old days).<br>
>And of course with a few default Interceptors. But that’s really it.<br>
><br>
>LieGrue,<br>
>strub<br>
><br>
><br>
>> Am 19.03.2015 um 19:14 schrieb arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>>:<br>
>><br>
>> Hi<br>
>><br>
>> On Thursday, March 19, 2015, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> wrote:<br>
>> >> but opposed to ee concurrency utilities<br>
>> ><br>
>> > I thought this was by mistake rather than design?<br>
>><br>
>><br>
>><br>
>> As far as I remember there was a long discussion on the EJB EG and it<br>
>>was intentionally that @Asynchronous does NOT propagate any information<br>
>>about the session, security, and don’t even share the same pool instance<br>
>>from @Stateless (pool ~what we have as @RequestScoped).<br>
>><br>
>> Slightly off topic perhaps, but @Stateless is difficult to map to a<br>
>>(CDI) scope. Everytime a method is called on a proxy, a different actual<br>
>>bean instance can be used (but it can also be the same bean instance as<br>
>>used for the previous call from the same thread)<br>
>><br>
>> The concept is actually not that far removed from a message passing<br>
>>paradigm, but using synchronous communication and a typed target.<br>
>><br>
>> Kind regards,<br>
>> Arjan Tijms<br>
>><br>
>><br>
>><br>
>> The reason is that EJB is all about removing concurrency complexity<br>
>>from the user as good as possible. The other problem is that you don’t<br>
>>have it under control how long the new thread will run. And the Session<br>
>>might be looong time dead already. Another issue is with TX handling.<br>
>>The JPA spec and also JTA spec (TransactionSynchronizationRegistry)<br>
>>defines that a transaction must not be used ‚concurrently‘. Means they<br>
>>only must be assigned to a very single Thread.<br>
>><br>
>> Even with servlet 3.0 async requests you have a ServletRequest only<br>
>>attached to a very single thread AT EACH TIME (means the thread might<br>
>>switch, but it’s max 1 at a time).<br>
>><br>
>><br>
>><br>
>> LieGrue,<br>
>> strub<br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>>code under the Apache License, Version 2<br>
>>(<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>provided on this list, the provider waives all patent and other<br>
>>intellectual property rights inherent in such information.<br>
><br>
><br>
>_______________________________________________<br>
>cdi-dev mailing list<br>
><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
>Note that for all code provided on this list, the provider licenses the<br>
>code under the Apache License, Version 2<br>
>(<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>provided on this list, the provider waives all patent and other<br>
>intellectual property rights inherent in such information.<br>
<br>
</div></div></blockquote></div><br></div></div>