3:39 p.m.
Hi,
On Thu, Mar 19, 2015 at 8:34 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
> 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.
With the small complication that @Stateless beans are considered @Dependent
in CDI (see https://issues.jboss.org/browse/CDI-414 for a consequence this
has).
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.
I don't really agree.
@RequestScoped will give you the same bean as long as the same request
scope is active for the caller. Every call is guaranteed to go to the same
bean.
For @Stateless the situation is actually reversed. There is no scope that
the caller is in. Every call the caller makes on a bean may go to a
difference instance. Conceptually it's like a method call results in a
package containing the call details being put on a queue, then a *random*
bean is chosen from a pool or created on the spot to process that package.
Then when it finishes processing the result is returned to the caller and
that random bean is put back into the pool or is immediately destroyed.
That's IMHO really nothing like @RequestScoped.
With a bit of imagination you could possibly say it's @MethodScoped. This
scope is independent of any context of the caller, and it starts as soon as
the call is made and it ends when the call exits. Within the context of
this single method call the bean instance is guaranteed to be active.
@PoolScoped is tempting, but not possible the way the EJB spec is defined
now. The reason is simply that there's nothing in the spec that mandates
stateless beans to be pooled. EJB Entity Beans if I'm not mistaken had a
pooling requirement, but for stateless beans the spec merely hints that
those beans *might* be pooled.
At any length, @PoolScoped would define the life-time of a bean (when it's
constructed and when it's destroyed) indeed, but it would mean nothing for
the caller. A caller can't ever be in the scope of the imaginary pool scope
for a particular bean.
Kind regards,
Arjan Tijms
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.