[cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages

[Nigel Deakin]

On 26/08/2015 10:51, arjan tijms wrote:
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> <rmannibucau at 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