You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Sanjiva Weerawarana <sa...@watson.ibm.com> on 2002/10/29 17:12:36 UTC
thread local storage and EJBs
(I don't know why I didn't get these messages .. thanks Pavel
for pointing them out.)
"WJCarpenter" bill-soap@carpenter.org writes:
> I believe using ThreadLocal will make the code technically ineligible
> for use by EJBs, but I don't know if there are any EJB containers which
> enforce that.
Hmm .. interesting. I thought it was our WebSphere guys who suggested
the thread local solution .. and obviously they breathe EJBs. Bill,
can you confirm/deny this pls?
THanks,
Sanjiva.
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: thread local storage and EJBs
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
No, the whole point of thread local is that its thread specific.
Hence there's no way that two threads can share the stuff as its
in a specific thread object! Hence, no synchronization necessary.
Sanjiva.
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Wednesday, October 30, 2002 7:08 AM
Subject: Re: thread local storage and EJBs
> > "WJCarpenter" bill-soap@carpenter.org writes:
> >> I believe using ThreadLocal will make the code technically ineligible
> >> for use by EJBs, but I don't know if there are any EJB containers
> >> which enforce that.
> >
> > Hmm .. interesting. I thought it was our WebSphere guys who suggested
> > the thread local solution .. and obviously they breathe EJBs. Bill, can
> > you confirm/deny this pls?
>
> Have a look at the EJB 2.0 spec, Appendix C, section C.1.2, "Programming
> Restrictions":
>
> An enterprise Bean must not use thread synchronization primitives to
> synchronize execution of multiple instances.
>
> I was imagining that the ThreadLocal implementation must have some
> synchronization in it, but now that I think about it, maybe that's not
> a necessity. (Regardless, billions of 3rd party packages have at least
> the occasional use of "syncrhonized", and you can't generally sniff that
> out except via JavaDocs. So, my intuition is that most app servers
> don't enforce this. Hence, my waffly "tecnically ineligible".)
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
Re: thread local storage and EJBs
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
No, the whole point of thread local is that its thread specific.
Hence there's no way that two threads can share the stuff as its
in a specific thread object! Hence, no synchronization necessary.
Sanjiva.
----- Original Message -----
From: "WJCarpenter" <bi...@carpenter.org>
To: <so...@xml.apache.org>
Sent: Wednesday, October 30, 2002 7:08 AM
Subject: Re: thread local storage and EJBs
> > "WJCarpenter" bill-soap@carpenter.org writes:
> >> I believe using ThreadLocal will make the code technically ineligible
> >> for use by EJBs, but I don't know if there are any EJB containers
> >> which enforce that.
> >
> > Hmm .. interesting. I thought it was our WebSphere guys who suggested
> > the thread local solution .. and obviously they breathe EJBs. Bill, can
> > you confirm/deny this pls?
>
> Have a look at the EJB 2.0 spec, Appendix C, section C.1.2, "Programming
> Restrictions":
>
> An enterprise Bean must not use thread synchronization primitives to
> synchronize execution of multiple instances.
>
> I was imagining that the ThreadLocal implementation must have some
> synchronization in it, but now that I think about it, maybe that's not
> a necessity. (Regardless, billions of 3rd party packages have at least
> the occasional use of "syncrhonized", and you can't generally sniff that
> out except via JavaDocs. So, my intuition is that most app servers
> don't enforce this. Hence, my waffly "tecnically ineligible".)
> --
> bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: thread local storage and EJBs
Posted by WJCarpenter <bi...@carpenter.org>.
> "WJCarpenter" bill-soap@carpenter.org writes:
>> I believe using ThreadLocal will make the code technically ineligible
>> for use by EJBs, but I don't know if there are any EJB containers
>> which enforce that.
>
> Hmm .. interesting. I thought it was our WebSphere guys who suggested
> the thread local solution .. and obviously they breathe EJBs. Bill, can
> you confirm/deny this pls?
Have a look at the EJB 2.0 spec, Appendix C, section C.1.2, "Programming
Restrictions":
An enterprise Bean must not use thread synchronization primitives to
synchronize execution of multiple instances.
I was imagining that the ThreadLocal implementation must have some
synchronization in it, but now that I think about it, maybe that's not
a necessity. (Regardless, billions of 3rd party packages have at least
the occasional use of "syncrhonized", and you can't generally sniff that
out except via JavaDocs. So, my intuition is that most app servers
don't enforce this. Hence, my waffly "tecnically ineligible".)
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Re: thread local storage and EJBs
Posted by WJCarpenter <bi...@carpenter.org>.
> "WJCarpenter" bill-soap@carpenter.org writes:
>> I believe using ThreadLocal will make the code technically ineligible
>> for use by EJBs, but I don't know if there are any EJB containers
>> which enforce that.
>
> Hmm .. interesting. I thought it was our WebSphere guys who suggested
> the thread local solution .. and obviously they breathe EJBs. Bill, can
> you confirm/deny this pls?
Have a look at the EJB 2.0 spec, Appendix C, section C.1.2, "Programming
Restrictions":
An enterprise Bean must not use thread synchronization primitives to
synchronize execution of multiple instances.
I was imagining that the ThreadLocal implementation must have some
synchronization in it, but now that I think about it, maybe that's not
a necessity. (Regardless, billions of 3rd party packages have at least
the occasional use of "syncrhonized", and you can't generally sniff that
out except via JavaDocs. So, my intuition is that most app servers
don't enforce this. Hence, my waffly "tecnically ineligible".)
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>