[concurrency-interest] dealing with people that questionvisibility problems

Ernst, Matthias matthias.ernst at coremedia.com
Wed Feb 21 12:41:17 EST 2007


> The visibility problem here, is that employeeDao, set by the thread
> that constructed the employeeManager, isn't safely published and
> doesn't have to be visible in other threads. 

Peter,

access to singleton beans is correctly synchronized by the spring
application context - construction and publication happen under the lock
of the app context. After that the fields are effectively final.

Additionally, by default, the instantiation of the singletons already
happens during the construction of the spring application context which
in turn is loaded at web application initialization. Only after that do
other threads get to access the application context. I do expect that
the servlet container safely publishes the web application from the
initializer thread to request handler threads. 

I've had a long discussion about that here:
http://weblogs.java.net/blog/tomwhite/archive/2006/09/are_your_beans_1.h
tml


> The problem can be solved in a few ways:
> make employeeDao volatile. 

Even if it were a problem, I do not particularly like that
recommendation. I'd not try to solve the problem at this level. This is
too low level, there are too many object associations to protect, you'll
lose oversight and if you add volatile everywhere, you're back to
sequential consistency. I would rather make sure that the whole object
graph is effectively immutable and safely published at the root. This
makes the happens-before-relationship dead simple: object graph creation
happens-entirely-before access. Selectively apply "visibility
engineering" only where that is impossible.

I've once tried to express that sentiment here:
http://mernst.org/blog/rss.xml#volatile-is-the-new-synchronized

Matthias

-- 
matthias.ernst at coremedia.com
software architect
+49.40.32 55 87.503



More information about the Concurrency-interest mailing list