Hi Andy, Thank you very much for your feedback, but I think there is a slight misunderstanding here: I know the order in which a servlet is initialized and put into service, and this question is not related to that. It's related to the _visibility_ of the field.
The question is about the thread safety of the field access: if you carefully check the details of javax.servlet.GenericServlet#config and compare the implementation to the sample "NoVisibility" from the book Java Concurrency in Practice, then it is seems to follow the same pattern, which is "not thread-safe because the value field is accessed from both get and set without synchronization. Among other hazards, it is susceptible to stale values: if one thread calls set, other threads calling get may or may not see that update." [1]. Personally, I would like to understand why this implementation is not (if not) susceptible to the stale values phenomenon [2]; there might be someone, who can point me to the right direction. Thanks, Peter [1] Java Concurrency in Practice: Chapter 3. Sharing Objects 3.1 Visibility [2] https://www.javacodegeeks.com/2014/08/java-concurrency-tutorial-visibility-between-threads.html On Mon, Nov 28, 2016 at 6:08 AM, andreas <andr...@junius.info> wrote: > ---- On Fri, 25 Nov 2016 23:02:00 +0930 Péter Gergely Horváth wrote ---- > >Hi All, > > > >I am wondering why calling javax.servlet.Servlet#getServletConfig() is > >thread safe: if you check the implementation in > > javax.servlet.GenericServlet from servlet API 3.0.1, you see the > following: > > > >package javax.servlet; > > > >// lines omitted > > > >public abstract class GenericServlet > > implements Servlet, ServletConfig, java.io.Serializable > >{ > > // lines omitted > > > > private transient ServletConfig config; > > > > // lines omitted > > > > public void init(ServletConfig config) throws ServletException { > > this.config = config; > > this.init(); > > } > > > > // lines omitted > > > > public ServletConfig getServletConfig() { > > return config; > > } > > // lines omitted > >} > > > > > >The field config is written in init(ServletConfig) without any > >synchronization, locking or config being volatile, while > getServletConfig() > >could be called anytime from any later worker thread of the servlet > >container. I took a quick look into Tomcat/Catalina code base, however I > >see no indication of the servlet container performing any magic, which > >would guarantee thread safe access to field config through > >getServletConfig() from e.g. > >javax.servlet.GenericServlet#service(ServletRequest, ServletResponse) and > >the corresponding methods in javax.servlet.http.HttpServlet. > > > >Am I missing something here? What will guarantee that if Thread A is used > >to init(ServletConfig) then Thread B calling getServletConfig() will see > >the correct state of the field config (Java "happens-before"), and not > e.g. > >null? > > > >I am asking this because I have seen some legacy code, where a servlet > >stored something into a field inside the init() method, which was then > used > >from within a javax.servlet.http.HttpServlet#doGet or > >javax.servlet.http.HttpServlet#doPost method, without synchronization of > >any kind like this: > > > >public class FoobarServlet extends HttpServlet { > > > > private FoobarService foobarService; > > > > @Override > > public void init() throws ServletException { > >this.foobarService = // ... acquire foobarService > > } > > protected void doGet(HttpServletRequest request, HttpServletResponse > >response) throws ServletException, IOException { > > List<Foobar> foobars = this.foobarService.getFoobars(); // read the > >field WITHOUT synchronization > > // ... > > } > > // ... > >Is this approach (having no synchronization, locking or the field being > >volatile) correct? I assumed it is not, seeing something like that in the > >servlet API is quite confusing. > > > > > >What do you think? > > > >Thanks, > >Peter > > > A Servlet will process requests only if it is fully initialized, i.e. init > has been executed. The init method gets called only once and the servlet > config won't change afterwards. I don't think there is need for > synchronization. The same is probably valid for your own objects. Problems > arise when individual requests change the state of these objects. > > Andy > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
