5

I've been exposing beans in our Spring web applications in case we need to make configuration changes on the fly. Recently I've been reviewing concurrency and I started to wonder what happens in other threads when you mutate one of these beans through JMX?

Does JMX have some way of forcing a memory model refresh so you don't need to worry about making the field volatile/synchronized to ensure other threads see the change?

When Tomcat creates a new thread to handle a request, that thread will see the changes even if the field is not thread-safe, correct? So unless I need the change to immediately take effect in current request threads is there any reason to worry about concurrency issues?

Arlo
  • 1,331
  • 2
  • 15
  • 26
  • Arlo, can you give an example how you are mutating your beans using JMX? – Rob Kielty Apr 27 '12 at 21:51
  • @Rob - String fields that are used to build URLs or booleans to disable functionality. I'm guessing that when a new thread is spawned by Tomcat to handle a request the act of creating a thread gets the latest value in memory (even if the field isn't volatile), but I just wanted to be sure. In my case I'm not concerned about current active threads immediately seeing the mutation, but I was curious about it. According to Gray JMX doesn't do anything special in terms of concurrency. – Arlo Apr 27 '12 at 22:19

1 Answers1

5

The JMX handler is not a special thread. Any changes there that need to be seen in other threads will need to be marked as volatile or synchronized.

// this needs to be volatile because another thread is accessing it
private volatile boolean shutdown;
...

@JmxOperation(description = "Shutdown the server")
public void shutdownSystem() {
   // this is set by the JMX connection thread
   shutdown = true;
}

That said, typically JMX values are statistics or configuration settings that I don't mind being lazily updated when the next memory barrier is crossed. This applies to counters and other debug information as well as booleans and other values that are only set by the JMX although they are used by other threads. In those cases, I do not mark the fields as volatile and it hasn't bitten us yet. YMMV.

FYI, the @JmxOperation annotation is from my SimpleJmx library.

Gray
  • 115,027
  • 24
  • 293
  • 354