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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 30, 2002 7:08 AM Subject: Re: thread local storage and EJBs > > "WJCarpenter" [EMAIL PROTECTED] 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".) > -- > [EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 > 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 > > > > > -- > To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org> > For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org> -- To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
