[concurrency-interest] Spring DispatcherServlet safe publication question

Tim Peierls tim at peierls.net
Thu Mar 6 07:41:42 EST 2008


On Thu, Mar 6, 2008 at 2:58 AM, Dhanji R. Prasanna <dhanji at gmail.com> wrote:

> Or is it because the servlet container's startup thread locks (presumably)
> when going thru init?


That wouldn't be enough, there would have to be a matching lock around every
service call.

Last time I looked, the Servlet spec stopped short of saying that there is a
happens-before edge between init() and service(). (The word "before" without
the "happens-" prefix doesn't count.) It's possible that this has been
tightened up, but my own habit is to be extra cautious, and to synchronize
access to (or make volatile) all non-final fields of a servlet.

As JCiP 4.5.1 points out, however, sometimes you have to assume, when
dealing with ambiguous documentation, that a framework is doing the right
thing, because it makes no sense for it to do otherwise. And gazillions of
happy Spring users haven't complained yet. :-)

--tim


On Thu, Mar 6, 2008 at 6:45 PM, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
>
> > Jason:
> > But the fields are not volatile, is there a guarantee that subsequent
> > request threads will see the value set by init()?
> > Dhanji.
> >
> >
> > On Thu, Mar 6, 2008 at 2:43 PM, Jason T. Greene <jason.greene at redhat.com>
> > wrote:
> >
> > > Hi Dhanji,
> > >
> > > This is OK, since the servlet spec guarantees that init() is called
> > > only
> > > once, and before any requests are serviced.
> > >
> > > Dhanji R. Prasanna wrote:
> > > > Hello again,
> > > >
> > > > This question has been bugging me for a *long* time. Nobody (and no
> > > > docs) seem to adequately address this problem for me.
> > > >
> > > > Spring's
> > > > DispatcherServlet:
> > > http://fisheye1.cenqua.com/browse/springframework/spring/src/org/springframework/web/servlet/DispatcherServlet.java?r=1.100
> > > > ...has several non-volatile, non-final fields for various pluggable
> > > > services (ThemeResolver, ViewResolver, etc.). These are set by
> > > equally
> > > > various private unsynchronized methods which cascade down from
> > > > HttpServlet.init(), itself also unsynchronized.
> > > >
> > > > The problem I have is that this seems like it could lead to
> > > incoherent
> > > > values between the startup thread's view of DispatcherServlet and
> > > any
> > > > subsequent request threads. Since there is no lock or
> > > synchronization, I
> > > > cannot find a guarantee that request threads will see the value set
> > > in
> > > > the init thread (even though they are chronologically sequenced ok).
> > > All
> > > > these fields are also non-volatile. It looks like a classic unsafe
> > > > publication problem to me.
> > > >
> > > > Worse, there are no default values, so request threads could end up
> > > > biting NPEs.
> > > >
> > > > This seems like a gross flaw in code that's deployed virtually
> > > > everywhere. Why isn't there more clamor about this? Or am I just
> > > totally
> > > > nuts (I *hope* so)?
> > > > I know Tim has talked for a long time about (lack of) safe
> > > publication
> > > > guarantees in the Spring injector itself... but I could not find any
> > > > concrete examples.
> > > >
> > > > @Jason: Yes I have JCiP, though it was hell finding it in Australian
> > > > book stores--thanks for the reck! =)
> > > >
> > > > Dhanji.
> > > >
> > > >
> > > >
> > > ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > Concurrency-interest mailing list
> > > > Concurrency-interest at altair.cs.oswego.edu
> > > > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > >
> > > --
> > > Jason T. Greene
> > > JBoss, a division of Red Hat
> > >
> >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080306/b53b6568/attachment.html 


More information about the Concurrency-interest mailing list