2:56 p.m.
Are SeContainer and SeContainerInitializer safe for concurrent use by
multiple threads? The string "concurren" shows up only four times in the
2.0 specification but not in this context.
I'm most interested in whether it is guaranteed that one thread may call
SeContainer::initialize and another may call SeContainer::close.
I'm assuming that this is *not* guaranteed.
Best,
Laird
3:01 p.m.
I would say that this is not guaranteed.
________________________________
From: cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org> on behalf of
Laird Nelson <ljnelson(a)gmail.com>
Sent: Wednesday, December 7, 2016 3:56 PM
To: cdi-dev(a)lists.jboss.org
Subject: [cdi-dev] Thread safety of SeContainer and SeContainerInitializer
Are SeContainer and SeContainerInitializer safe for concurrent use by multiple threads?
The string "concurren" shows up only four times in the 2.0 specification but not
in this context.
I'm most interested in whether it is guaranteed that one thread may call
SeContainer::initialize and another may call SeContainer::close.
I'm assuming that this is not guaranteed.
Best,
Laird
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary,
and/or privileged information which should be treated accordingly. If you are not the
intended recipient, please notify the sender immediately by return e-mail, delete this
message, and destroy all physical and electronic copies. Thank you.
3:37 a.m.
I agree with John, it's not guaranteed. However, the original intention
(based on Weld SE impl) was:
* SeContainerInitializer is not thread-safe and should not be shared
between threads
* it should be safe to call SeContainer.close() from any thread
Martin
Dne 7.12.2016 v 22:01 John Ament napsal(a):
I would say that this is not guaranteed.
------------------------------------------------------------------------
*From:* cdi-dev-bounces(a)lists.jboss.org
<cdi-dev-bounces(a)lists.jboss.org> on behalf of Laird Nelson
<ljnelson(a)gmail.com>
*Sent:* Wednesday, December 7, 2016 3:56 PM
*To:* cdi-dev(a)lists.jboss.org
*Subject:* [cdi-dev] Thread safety of SeContainer and
SeContainerInitializer
Are SeContainer and SeContainerInitializer safe for concurrent use by
multiple threads? The string "concurren" shows up only four times in
the 2.0 specification but not in this context.
I'm most interested in whether it is guaranteed that one thread may call
SeContainer::initialize and another may call SeContainer::close.
I'm assuming that this is /not/ guaranteed.
Best,
Laird
------------------------------------------------------------------------
NOTICE: This e-mail message and any attachments may contain
confidential, proprietary, and/or privileged information which should be
treated accordingly. If you are not the intended recipient, please
notify the sender immediately by return e-mail, delete this message, and
destroy all physical and electronic copies. Thank you.
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
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.
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
3:56 p.m.
(Resurrecting this thread. Happy New Year!)
Another (related) case I had a question about.
Suppose I have the standard SeContainer "block" like this:
try (final SeContainer container = initializer.initialize()) {
// stuff goes here
}
Inside that block, may I start threads and have them do things with the
container variable? It sounds like strictly speaking no, I may not—i.e.
that the specification, since it says nothing one way or the other about
threading, therefore implies that only one thread may, say, iterate over
the container (either using its iterator() or stream() methods).
On the other hand, I see no restriction in the specification on the
creation of threads from, say, a managed bean, which means it is always
possible that at any point an Instance object may be used by many threads.
Or, further, since events may be fired asynchronously, then it would *seem* to
follow that iteration over an Instance must be thread safe.
Should the specification include language related to concurrency in these
matters and others?
Best,
Laird
On Thu, Dec 8, 2016 at 1:37 AM Martin Kouba <mkouba(a)redhat.com> wrote:
I agree with John, it's not guaranteed. However, the original
intention
(based on Weld SE impl) was:
* SeContainerInitializer is not thread-safe and should not be shared
between threads
* it should be safe to call SeContainer.close() from any thread
Martin
Dne 7.12.2016 v 22:01 John Ament napsal(a):
> I would say that this is not guaranteed.
>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces(a)lists.jboss.org
> <cdi-dev-bounces(a)lists.jboss.org> on behalf of Laird Nelson
> <ljnelson(a)gmail.com>
> *Sent:* Wednesday, December 7, 2016 3:56 PM
> *To:* cdi-dev(a)lists.jboss.org
> *Subject:* [cdi-dev] Thread safety of SeContainer and
> SeContainerInitializer
>
> Are SeContainer and SeContainerInitializer safe for concurrent use by
> multiple threads? The string "concurren" shows up only four times in
> the 2.0 specification but not in this context.
>
> I'm most interested in whether it is guaranteed that one thread may call
> SeContainer::initialize and another may call SeContainer::close.
>
> I'm assuming that this is /not/ guaranteed.
>
> Best,
> Laird
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> 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.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
1:39 a.m.
Dne 5.1.2017 v 22:56 Laird Nelson napsal(a):
(Resurrecting this thread. Happy New Year!)
Another (related) case I had a question about.
Suppose I have the standard SeContainer "block" like this:
try (final SeContainer container = initializer.initialize()) {
// stuff goes here
}
Inside that block, may I start threads and have them do things with the
container variable? It sounds like strictly speaking no, I may not—i.e.
that the specification, since it says nothing one way or the other about
threading, therefore implies that only one thread may, say, iterate over
the container (either using its iterator() or stream() methods).
I believe you can. It should be safe to use an initialized container
instance from multiple threads. The spec does not explicitly mention
this but it can't cover every possibility ;-)
On the other hand, I see no restriction in the specification on the
creation of threads from, say, a managed bean, which means it is always
possible that at any point an Instance object may be used by many
threads.
You can create a new thread from within a managed bean. BUT there are
few snags you should be aware of. I.e. in Java EE you should not create
your own threads and if you do, only dependent and application context
will work as usual.
See also http://weld.cdi-spec.org/documentation/#0
Or, further, since events may be fired asynchronously, then it
would /seem/ to follow that iteration over an Instance must be thread safe.
Should the specification include language related to concurrency in
these matters and others?
I think that would require a great deal of effort. But feel free to
create a spec issue for CDI 2.1+.
Best,
Laird
On Thu, Dec 8, 2016 at 1:37 AM Martin Kouba <mkouba(a)redhat.com
<mailto:mkouba@redhat.com>> wrote:
I agree with John, it's not guaranteed. However, the original intention
(based on Weld SE impl) was:
* SeContainerInitializer is not thread-safe and should not be shared
between threads
* it should be safe to call SeContainer.close() from any thread
Martin
Dne 7.12.2016 v 22:01 John Ament napsal(a):
> I would say that this is not guaranteed.
>
>
>
>
------------------------------------------------------------------------
> *From:* cdi-dev-bounces(a)lists.jboss.org
<mailto:cdi-dev-bounces@lists.jboss.org>
> <cdi-dev-bounces(a)lists.jboss.org
<mailto:cdi-dev-bounces@lists.jboss.org>> on behalf of Laird Nelson
> <ljnelson(a)gmail.com <mailto:ljnelson@gmail.com>>
> *Sent:* Wednesday, December 7, 2016 3:56 PM
> *To:* cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> *Subject:* [cdi-dev] Thread safety of SeContainer and
> SeContainerInitializer
>
> Are SeContainer and SeContainerInitializer safe for concurrent use by
> multiple threads? The string "concurren" shows up only four times in
> the 2.0 specification but not in this context.
>
> I'm most interested in whether it is guaranteed that one thread
may call
> SeContainer::initialize and another may call SeContainer::close.
>
> I'm assuming that this is /not/ guaranteed.
>
> Best,
> Laird
>
------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which
should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this
message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> 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.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
1:50 a.m.
On Thu, Jan 5, 2017 at 11:39 PM Martin Kouba <mkouba(a)redhat.com> wrote:
Dne 5.1.2017 v 22:56 Laird Nelson napsal(a):
> Suppose I have the standard SeContainer "block" like this:
>
> try (final SeContainer container = initializer.initialize()) {
> // stuff goes here
> }
>
> Inside that block, may I start threads and have them do things with the
> container variable?
I believe you can. It should be safe to use an initialized container
instance from multiple threads. The spec does not explicitly mention
this but it can't cover every possibility ;-)
Sure; that's fair. I guess…maybe there's a blanket statement that could be
added to the specification? Something that indicates that *unless
otherwise indicated*, 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.
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.
You can create a new thread from within a managed bean. BUT there
are
few snags you should be aware of. I.e. in Java EE you should not create
your own threads
Sure; of course not.
and if you do, only dependent and application context
will work as usual.
Right.
Thanks.
> Should the specification include language related to concurrency
in
> these matters and others?
I think that would require a great deal of effort. But feel free to
create a spec issue for CDI 2.1+.
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.
Best,
Laird
2915
days inactive
2945
days old
5 comments
3 participants
participants (3)
-
John Ament -
Laird Nelson -
Martin Kouba