[concurrency-interest] Spring DispatcherServlet safe publication question

Jed Wesley-Smith jed at atlassian.com
Sun Mar 9 23:18:41 EDT 2008


As far as I am aware, the DispatcherServlet is actually initialised by 
Spring (at least in terms of the setters being called). Spring 
components with setter injection are initialised correctly (with 
happens-before semantics) and are subsequently effectively immutable as 
long as no client code changes the references. It's one of the things I 
hate about setter injection that you have to trust the framework to do 
the right thing.

So, it has nothing to do with the Servlet spec - it's entirely down to 
Spring.

Tim Peierls wrote:
> On Thu, Mar 6, 2008 at 10:43 AM, Jason T. Greene 
> <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>
>     Tim Peierls wrote:
>     > On Thu, Mar 6, 2008 at 2:58 AM, Dhanji R. Prasanna
>     <dhanji at gmail.com <mailto:dhanji at gmail.com>
>     > <mailto:dhanji at gmail.com <mailto: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.
>
>     Not true. As long as the instance fields are not yet visible
>     (published)
>     to other threads, and they are never written to afterwards they are
>     effectively immutable.
>
>
> Circular reasoning: You can't guarantee that those writes aren't yet 
> visible to other reading threads unless there is a /happens-before/ 
> relationship between init() and service(), and the spec isn't clear 
> about that. I understand the intent, but ... horseshoes and hand-grenades.
>
>
>     Since the spec requires init() to be ran only once and complete
>     before any service method is called, 
>
>
> There's that pesky "before" again. If only the spec used 
> /happens-before/ or something equivalent to it.
>
>  
>
>     and since instance fields are only ever
>     accessed by service methods, they can be effectively immutable. I do
>     agree the spec should make this more clear. I will email the
>     servlet EG
>     about that.
>
>
> Thanks!
>
>  
>
>     > 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. :-)
>
>     It's funny that you bring this up, because I took a look at the tomcat
>     source, and sadly they are using DCL to meet the init() requirements
>     (will file a bug on this) :(
>
>     if (instance == null) {
>       synchronized (this) {
>         if (instance == null) {
>           try {
>             instance = loadServlet();
>           } catch (ServletException e) {
>             throw e;
>           } catch (Throwable e) {
>             throw new ServletException(..., e);
>           }
>         }
>       }
>     }
>
>     So, your suggestion of guarding against broken containers with a
>     volatile isn't so bad.
>
>
> Thanks, again! :-)
>
> --tim
> ------------------------------------------------------------------------
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>   



More information about the Concurrency-interest mailing list