<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 5, 2017 at 11:39 PM Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 5.1.2017 v 22:56 Laird Nelson napsal(a):<br class="gmail_msg">> Suppose I have the standard SeContainer "block" like this:<br class="gmail_msg">
><br class="gmail_msg">
> try (final SeContainer container = initializer.initialize()) {<br class="gmail_msg">
> // stuff goes here<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> Inside that block, may I start threads and have them do things with the<br class="gmail_msg">
> container variable?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
I believe you can. It should be safe to use an initialized container<br class="gmail_msg">
instance from multiple threads. The spec does not explicitly mention<br class="gmail_msg">
this but it can't cover every possibility ;-)<br class="gmail_msg"></blockquote><div><br></div><div>Sure; that's fair. I guess…maybe there's a blanket statement that could be added to the specification? Something that indicates that <i>unless otherwise indicated</i>, core CDI objects (not sure offhand what these are, but things like BeanManager, CDI, Instance, Context, etc.) used in a Java SE context are safe for concurrent use by multiple threads.</div><div><br></div><div>To state the obvious, I'm not a fan of "try it; see if it works", since I don't know what any given implementation is going to do.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can create a new thread from within a managed bean. BUT there are<br class="gmail_msg">
few snags you should be aware of. I.e. in Java EE you should not create<br class="gmail_msg">
your own threads </blockquote><div><br></div><div>Sure; of course not.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and if you do, only dependent and application context<br class="gmail_msg">
will work as usual.<br class="gmail_msg"></blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">See also <a href="http://weld.cdi-spec.org/documentation/#0" rel="noreferrer" class="gmail_msg" target="_blank">http://weld.cdi-spec.org/documentation/#0</a><br class="gmail_msg"></blockquote><div><br></div><div>Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Should the specification include language related to concurrency in<br class="gmail_msg">
> these matters and others?<br class="gmail_msg">
<br class="gmail_msg">
I think that would require a great deal of effort. But feel free to<br class="gmail_msg">
create a spec issue for CDI 2.1+.<br class="gmail_msg"></blockquote><div><br></div><div>OK. A blanket statement or two, so that exceptional cases can then be documented on a case-by-case basis would seem to be the way to go here. I'll file a spec issue. Thanks for your time.</div><div><br></div><div>Best,</div><div>Laird</div></div></div>