[cdi-dev] On @Observes for async events

[arjan tijms]

Hi,

On Thu, Mar 19, 2015 at 8:52 PM, Jens Schumann <
jens.schumann at 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 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/75550057/attachment.html