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 <javascript:;>
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.