[concurrency-interest] Safety of initializations in Servlet init
kkr at trifork.com
Tue Aug 3 01:23:08 EDT 2010
On 02/08/2010, at 15.41, Matthias Ernst wrote:
> I think the keywords are "must...before". I'd argue that this prose
> naturally translates to "happens before" in JMM lingo. The only
> reasonable ways to implement this requirement introduce happens-before
> relationships: for example the "worker pool threads" are only started
> after the init methods have run or the container worker safely
> communicates an initialization bit to the workers or a new,
> initialized servlet instance is safely published into some
If there are several servlets sharing a thread pool, then chances are it is already started, right?
But, yes, I agree it would be hard to implement this without creating a happens-before relationship since the request handling logic must check that the servlet has been initialized before calling the service method (I guess, at least this would require a volatile boolean read/write).
> Then "Write to servlet instance variables" happens-before "init-method
> finishes" happens-before "request is dispatched to servlet"
> happens-before "read from instance variable".
> If a container instead performed an unsafe busy wait loop on the
> servlet instance, there are probably more things to run away
> screamingly from such container...
> That said, back in the 4.x times, a chief Tomcat maintainer resisted
> to necessary synchronization related to session timeout and on-demand
> JSP compilation if I remember correctly. But those simply were bugs
> IMHO that undermined my trust in the implementation and not the spec.
;) Yes, that happened to me too: I recently saw the broken double checked locking in apache myfaces portlet bridge - the natural thing to think is "so what else is broken ..."
private void initBridge()
Perhaps many of the jsr specs would be more clear if JMM considerations were explicit.
Thanks for taking the time.
More information about the Concurrency-interest