On Sun, 2009-11-01 at 19:36 -0800, Craig McClanahan wrote:
> On Sun, Nov 1, 2009 at 6:59 PM, Chris Hubick <chris_at_hubick.com> wrote:
> > OK, so I finished enough of my conversion to the JAX-RS API to re-enable
> > threading, and immediately got a ConcurrentModificationException inside
> > java.util.ArrayList$Itr.next() when multiple threads (all inside the
> > request scope) try to simultaneously iterate (read-only) through the
> > List<Locale> returned by HttpHeaders.getAcceptableLanguages().
> >
>
> If you are accessing servlet request objects from more than one
> thread, you're breaking the rules of the Servlet Specification,
> whether or not you are using Jersey.
As mentioned in my initial email to this thread, when using the Servlet
API, I perform my own synchronization around any access I make to those
methods. I am not breaking any rules.
This question is, however, not about the Servlet API, which I mentioned
I am migrating away from. This question is about the thread safety of
JAX-RS API methods, which is determined by that specification,
regardless of whether it is implemented on top of the Servlet API or
not.
> What are you doing that needs to
> access this kind of thing from multiple threads?
I utilize the "Acceptable Languages" ("Accept-Language" header) to
determine the language of content to return to the client, as designed.
I have multiple threads, each generating separate pieces of that
content, which are later aggregated together.
> If there is indeed a valid use case for this, then yes, you are going
> to need to take responsibility for synchronizing access yourself.
Jersey could choose to offer a thread-safe JAX-RS implementation, even
if not strictly required by the specification. I am requesting
clarification as to if there is an intention to offer such a thing, as
well as the thread-safety requirements of the JAX-RS specification.
Thanks.
--
Chris Hubick
mailto:chris_at_hubick.com
http://www.hubick.com/chris/