<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 6:53 AM Nigel Deakin <<a href="mailto:nigel.deakin@oracle.com">nigel.deakin@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26/08/2015 10:51, arjan tijms wrote:<br>
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau<br>
> <<a href="mailto:rmannibucau@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=rmannibucau@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">rmannibucau@gmail.com</a>> wrote:<br>
>> Agree for provided scope but JMS + short time scopes will not match well in<br>
>> practise so i would worry more about not "default" scopes which can miss<br>
>> these events.<br>
><br>
> Short lived scopes like @RequestScoped may not be the best match indeed.<br>
><br>
> Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"<br>
> thing, e.g. there's the expectation that only the current thread will<br>
> access it. If the JMS provider will asynchronously call a method on<br>
> the bean instance from another thread, then this breaks this<br>
> assumption.<br>
<br>
That's an interesting point. Is there anything in the CDI spec which would forbid the use of a @RequestScoped JMS<br>
listener bean from another thread?<br></blockquote><div><br></div><div>The CDI spec still mandates that a request scope is started for delivery to MDBs. See <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context">http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context</a></div><div><br></div><div>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).</div><div><br></div><div>Likewise, we could say that a @TransactionScoped bean also applies here, since a JTA transaction should have been started by the RA.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Perhaps all that is needed is to make it clear to users that this is what would happen. The same issue would arise if<br>
the user injected a dependent-scoped JMS listener bean into a @RequestScoped bean.<br>
<br>
It's worth considering threading more generally. Although the JMS provider (resource adapter, actually) can make sure<br>
that the callback method won't be called from multiple JMS provider threads at the same time, it can't guarantee that an<br>
application thread won't be calling a business method on the bean at the same time. (Would it want to?)<br>
<br>
Nigel<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cdi-dev@lists.jboss.org&cc=&bcc=&su=&body=','_blank');return false;">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</blockquote></div></div>