It's too simplistic to make "always" or "never" statements on this topic -- you have to evaluate each use case on its own, based on the actual environment.
Synchronization is never an issue for single-threaded applications (like a stand-alone Java application), because there is never any potential for two threads to be accessing the same data structure at the same time. In a web application, however, you MUST synchronize around non-atomic changes to shared data that is accessibe to multiple threads (because the container will be sending multiple requests through your code at the same time). Among other places, that means you need to be careful with: * Objects stored in session or application scope, and nested objects that they refer to. * Instance variables (at the class level) in actions and servlets * Static variables Note that you don't have to worry about request scope attributes -- those are only accessible to the current request thread, and aren't an issue for thread safety. For example, the servlet container itself stores your session attributes in some sort of a data structure (Tomcat uses a HashMap, which is probably typical). Inside the implementation of HttpSession, access to this Map is synchronized inside methods like getAttribute() and setAttribute() because it has to be -- otherwise, simultaneous access from multiple requests could corrupt the data structure representing the map. In Struts, synchronization is done whenever data structures that Struts uses are mutable (i.e. they can be changed) from multiple threads at the same time. One place that is *not* necessary in Struts is accesses to the JavaBeans that represent the configuration data that was loaded from struts-config.xml. These beans have a "frozen" property that is set once the data has all been read in, which prevents further modification. Therefore, for example, Struts can look up the ActionMapping object describing a particular action (stored in a HashMap keyed by action name) without synchronization, because Struts guarantees that nothing will change. As for Vector and Hashtable (which do synchronization internally), I personally replace those with ArrayList and HashMap respectively so that I have the option of *not* synchronizing if I don't need to (for example, a temporary map stored only in a local variable, and therefore never accessible to multiple threads). The penalty, of course, is that I have to remember to synchronize when it IS necessary; but, for me, that's a good tradeoff. Craig On Thu, 21 Oct 2004 10:33:47 -0700, Randy Eckhoff <[EMAIL PROTECTED]> wrote: > I am evaluating struts and have a question about something I read in the > O'Reilly Jakarta Struts book. Specifically it says to not use the > synchronized keyword and to avoid Vector and Hashtable at all. > Considering that our system has been for a long time, this is actually a > huge thing for us. > > Is this still an issue in Struts 1.2? > > Is this statement only true if we use the taglibs? > > If we just use the controlling framework, we would be ok? > > I really need to understand this in much more detail other than just the > blanket statement: don't use the synchronized keyword. Is there a write > up somewhere on this? Googling didn't yield any decent hits. > > Thanks! > > Randy > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
