Controllers are singletons by default what impact does this

[Paul Taylor]

I Just realised that Controllers by default are singletons.

Doe this mean we should never declare instance variables because they will be reused such as a HashMap to hold the model.

Does this mean we have to worry about synchronisation or is that taken care of.

I also read that all beans are singletons by default which has confused me, doe sthis mean they are only used for services rather than holding data ?

[maward]

The same threading issues apply to any Servlet based software. This is because the Servlet container creates an instance of the Servlet and then invokes certain methods such as doGet() using multiple threads (each thread servicing a different HTTP request).

So there are many threading issues and you must be careful! In general don't re-use your model just as you suggested. However some types of data can take advantage of this singleton approach - for example data that you may want to set once but will remain the same for the life-time of the servlet such as a list of countries on a contact form. In this case you can do something like:

The following could be in a SimpleFormController for example:

private List countryList;

protected Map referenceData(HttpServletRequest request) {
  Map model = new HashMap();

  if (countryList == null) {
    // only get the countries the first time this Controller is used
    countryList = middleware.getAvailableCountries();
  }

  model.put("countryList", countryList);
}

The countries may then be displayed in a drop-down list in your form for each use of the form, but the hit of generating the list only happens once.

Java Servlet Programming from O'reilly is a good source of material regarding Servlet threading issues.

Hope that helps.

[Paul Taylor]

Thanks, not sure that your reference data example is really a good idea though as the reference data is only available to that controller. Usually the reference data would be required by more than one view/controller so would probably be better served by going in the Application Context.

Is Springs singleton approach really the best way forward ? I know we want to keep the controllers simple but it seems to limit how you use them a bit ?

[robh]

Paul,

I'm not sure what you mean with regards to being limited with Spring singleton controllers. If you were coding a servlet you wouldn't be able to store unsynchronized state because the same servlet instances if accessed by multiple threads.

In practise I have never seen any problems with the singleton controller approach because I have never had the need to have shared writable state in my controllers.

I'm wondering what case you have for storing state in the controller? Could you provide a more concerete example - perhaps I can recommend an approach.

Rob

[Paul Taylor]

Well in a project I worked on previously we had a similar DispatcherServlet/Controller idea but the controllers were newly created as requested. (The controllers were just POJOs)

And because new instances were created we didnt have to worry about synchronisation, perhaps you could give us an example of a synchronisation issue we need to worry about.

I suppose this must have introduced an overhead, but it meant we could declare instance variables which related to things such as Validation, a reference to a map for determining flow between pages (which was held per user session) and references to the httpSession,HttpRequest which meant all methods in the controller could access these commonly used parameters without having to pass them around anywhere.

Also because we had control of the hierachy we could add in useful methods into the top level controller, whereas with Spring we cant really do that.

[robh]

Paul,

You typically only need to worry about synchronization if you have writable state in fields. In a controller, you get access to the request, response and session as part of the handle method and validation is a separate concern that is handled by a Validator.

Typically, you won't encounter that many synchronization problems, because there are not too many (that I can think of) cases where you want to store writable state as fields in your controllers.

You can still create your own base classes - the controllers being singletons doesn't prevent this at all. Obviously, if you want to use a selection of Spring's base controller classes then you will encounter a problem - but you can circumvent this with a simple helper class.

Rob