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(a)gmail.com>:
Hi
On Thursday, March 19, 2015, Mark Struberg <struberg(a)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(a)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.