On 11 March 2015 at 04:43, Christopher Schultz <ch...@christopherschultz.net > wrote:
Basically, making a > servlet threadsafe only requires you to avoid any non-threadsafe class > members in the servlet itself... > Since we're tossing pennies, I've often wondered how the app-server achieves the effect that any instance-level fields set during an overridden setInitialContext(ServletContext) are guaranteed to 'happens-before' subsequent reads from overridden service(...) methods. I can only guess that the thread which invokes setInitialContext is the very same thread which *later *invokes aThread.start() on the worker threads ... there is a 'happens-before' relationship there, and since there is no volatile, final or synchronization involved, that's probably the one ... is it? That would kind of mean that when reloading a webapp, one would have to restart all the worker threads, right? Any comments? (I ask these only from curiosity). I stumbled across this in my IDE when I used an @ThreadSafe annotation on my servlet, but could put no @GuardedBy annotations on any of the instance fields, because I'm *not* actually using a lock or a synchronized block. (Thus my IDE whinged at me, and I retracted the @ThreadSafe from the Sevlet). cheers, David.
