Announcement Announcement Module
No announcement yet.
Class variables and singleton="yes" Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Class variables and singleton="yes"

    In my application i have a screen with some entry fields. The backing object of the form controller has variables to save the search criteria fields. (much like velocity and spring step by step)

    This works fine but ONLY for one user. I noticed that the class variables interfere when testing with multiple users and singleton="yes" for the controller bean and backing bean definition. When these beans are defined with singleton="no" it works fine for multiple users.

    Beans are preferably defined as singletons but i wonder whether these beans can have class variables when defined as singeleton="yes"?

    kind regards,

  • #2
    Hi Pete

    The standard Spring MVC works-in-90%-of-cases setup is to define your Controllers as singletons. This means that a single Controller instance can process many requests concurrently, in a programming style similar to the Servlet model. The fact that Controllers (typically) are singletons means that you should not maintain any conversational state in variables. You certainly can though, and nothing is explicitly preventing you from doing so, but you'd have to either serialize requests (thus totally blowing any notion of concurrency out of the water), or have some other mechanism for dealing with this.

    If you want the WebWork Command-style approach to Controllers, where a new Controller instance is instantiated to handle each and every request, then you may wish to investigate the ThrowawayController interface and attendant support classes. This approach does allow you to maintain conversational state in the Controller, because each Controller only services one request before being thrown away (hence the name).

    Typically you should not be defining the form backing object for a form Controller in your Spring configuration, as this form backing object is going to be maintaining the conversational state for a request. You should simply instantiate it directly in formBackingObject().



    • #3
      With Spring 2.0 you have the option of adding objects to your controller which have limited scope. These can store conversational information. A new one is created for appropriate scope (per-request, per-session or a custom scope you create). Take a look at the reference manual for more details.