On Sun, 2009-11-01 at 21:09 -0800, Craig McClanahan wrote:
> On Sun, Nov 1, 2009 at 8:08 PM, Chris Hubick <chris_at_hubick.com> wrote:
> > 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.
>
> The only safe ways to deal with this are either synchronize access to
> the underlying data, or (better) pull out everything you need as part
> of original processing in the resource method, then pass your own data
> objects to the various threads generating the content pieces. This is
> also likely to improve your overall architecture's modularity and
> testability, because the content producing logic in each thread would
> no longer be tied to either Servlet or JAX-RS APIs directly.
In my opinion, having code and data structures utilizing a broadly
understood and standard API is preferable to a custom API from a
maintenance perspective. Adding synchronization in the places it's
needed, although ugly, also generally results in less code overall than
writing custom data structures. More importantly, I can't "pull out"
access to things like SecurityContext.isUserInRole(String).
One of my major draws to Java was it's thread-safe library, it makes me
sad to see this design tenet fall ever further to the wayside.
Anyhow, thanks for your clarifications.
--
Chris Hubick
mailto:chris_at_hubick.com
http://www.hubick.com/chris/