On 26/08/2015 10:51, arjan tijms wrote:
On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.
Short lived scopes like @RequestScoped may not be the best match indeed.
Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
thing, e.g. there's the expectation that only the current thread will
access it. If the JMS provider will asynchronously call a method on
the bean instance from another thread, then this breaks this
assumption.
That's an interesting point. Is there anything in the CDI spec which would forbid the
use of a @RequestScoped JMS
listener bean from another thread?
Perhaps all that is needed is to make it clear to users that this is what would happen.
The same issue would arise if
the user injected a dependent-scoped JMS listener bean into a @RequestScoped bean.
It's worth considering threading more generally. Although the JMS provider (resource
adapter, actually) can make sure
that the callback method won't be called from multiple JMS provider threads at the
same time, it can't guarantee that an
application thread won't be calling a business method on the bean at the same time.
(Would it want to?)
Nigel