Thread Safe Java Beans
I was recently working on a Java program whose only interactions were through web services. The application accepted web service requests and, as part of its processing, made other web service requests to other services. I leveraged a couple of frameworks to simplify the web service interactions, namely Spring and Castor. Spring-WS provided the web service endpoint support and Castor did all my marshalling and unmarshalling.
At this point you may be asking what this has to do with Thread Safety. I am glad you asked. It could be that my title is misleading, but I believe the next paragraph will help resolve any apparent disconnect.
As part of integrating the marshalling and unmarshalling process involved in the web service, I needed to create JavaBeans™, which provide the objects housing the program’s data. However, since a framework was handling the marshalling and unmarshalling process, I never used the new keyword. Nor did I call the bean’s accessors or mutators directly when reading or writing the XML. Instead, the framework decided the order of get and set calls, and more to my point, I wondered whether the framework was free to multithread the interactions.
The reason for my concern was that one of my beans had a dependency between two properties. If one was set to a certain value, the other was impacted. The framework controlled the order of calls, so I had to deal with either being set first. Handling order was not a big issue, but what if their mutators were called simultaneously?
This led me to look more closely at the JavaBean™ specification. I was interested in whether it mentions anything about multi-threaded access. If it stated that beans should not expect multi-threaded access by default, then I was in good shape. Otherwise, the framework might have me at a disadvantage.
It turns out that the JavaBean™ specification does speak to multi-threading in very specific language. Here I quote from section 2.8 of Sun’s JavaBean™ 1.01 specification (linked below):
Java Beans [sic] should assume that they are running in a multi-threaded environment and that several different threads may be simultaneously delivering events and/or calling methods and/or setting properties.
It is the responsibility of each java bean developer to make sure that their bean behaves properly under multi-threaded access. For simple beans this can generally be handled by simply making all the methods “synchronized”.
That doesn’t leave much room for negotiation! At a minimum a compliant JavaBean™ must synchronize all of the methods that interact with the bean’s state. I say this because beans exist to preserve some state so we cannot simply code them with only threadsafe variables (e.g. locals and parameters).
I have never built a JavaBean™ in this fashion and would be concerned about locking issues. I also can’t imagine the performance implications of such a design principle. Luckly, after looking under the covers at the Castor code, I found that the bean accesses are single-threaded. Apparently most framework’s interact with beans in a single-threaded fashion, at least for now. It certainly appears that someday I could be in for a rude surprise!
All of this led me to another question, “When is a piece of code thread safe? ” In order to make such a determination one has to examine how the code is being used. A class that is thread safe in one situation may not be in another. That is a topic for another post.
Sun’s JavaBean™ Specification: http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html