On 26/08/2015 10:51, arjan tijms wrote:
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> <email@example.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
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?
The JMS provider would be responsible for retrieving a contextual reference to the bean and then invoking the method. The container should still be responsible for starting the request context (If I read this correctly).
Likewise, we could say that a @TransactionScoped bean also applies here, since a JTA transaction should have been started by the RA.
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?)
cdi-dev mailing list
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.