Issues with multithreading and controllers?

[brianstclair]

If I understand the Spring lifecycle, at least semi-correctly, then each singleton bean in my config file (or files) is instantiated once at startup and that same instance is supplied any time the bean is requested. It seems like there should be all kinds of issues with the controller beans (and any other singleton beans, for that matter) being used in multiple threads, especially in a web application, yet I haven't seen this issue discussed anywhere.

Do I need to avoid instance variables in my singleton beans (esp controllers), or at least synchronize access to them? It seems like not using instance variables is probably the best way to go in any case, at least with controllers. Come to think of it, most of my Spring-managed beans don't have much use for instance variables in any case...

Along the same lines, shouldn't the controller methods be synchronized to prevent multiple threads from messing with local variables?

I'm sure I'm missing something here - I'm not very familiar with threading issues in general. If anyone could shed some light on the issues, particularly in a web application, with controller and singleton beans and multithreading I would really appreciate it! Thanks in advance!

Brian St.Clair

[Stefan Arentz]

Along the same lines, shouldn't the controller methods be synchronized to prevent multiple threads from messing with local variables?

A spring Controller runs inside a Servlet and a Servlet is multi-threaded by default. This means that many requests could be handled by the same Controller simultaneously.

Read up about the Servlet threading model. The same applies to stuff running inside the servlet.

S.

[brianstclair]

Which is exactly my point. Many requests are handled by the same controller - multiple threads accessing it, but the same instance being accessed. Doesn't that come back to the basic issue of multithreading and synchronization? For example, if there were an instance variable inside a controller, couldn't the multiple threads independently modify that variable at unpredictable times and cause problems for other threads? Hope what I just said was clear, and thanks for the response Stefan.

Brian

[Jurijus Jarmakas]

I guess the key to understanding this is that every thread has its own stack.

[huydo]

Doesn't that come back to the basic issue of multithreading and synchronization? For example, if there were an instance variable inside a controller, couldn't the multiple threads independently modify that variable at unpredictable times and cause problems for other threads?

Brian

Everything you say is true but your assumption that synchronization is the only solution is not. The other solution is not to use instance variables which as far as I understand is the assumption with controllers.

[standev]

To the creator of the topic: just use HttpSession or Request Attributes (session scope and request scope variables respectively) instead of controller's instance variables for your needs.

[brianstclair]

Thanks to all who replied - greatly appreciated!

Brian

[vkotian]

Since servlet is multithreaded and we use Tiles Spring based delegator controller, what is the problem in using instance variables in action classes which are spring beans(not defined as singleton=false in configuration)? Per request, there is a seperate instance of servlet, and stack of spring beans is used. But we need the information to be persisted between the method calls for each request. I do not see multithreading problems here. But recently Fortify complained about this.
Is there anything wrong with my assumption?

[Hetal B]

Hi,

How about using ThreadLocal Variables i.e. for each thread it will create its own independent copy? Just incase its required that each thread has some kind of static variable at the thread level.

-Hetal

[F.Degenaar]

@vkotian: No, every request is handled by the same instance! Instance variables are bad, unless they are thread-safe like stateless services, constants etc.

@Hetal B: Thread-local variables only work per request. So creating method-scoped variables in the request handling method and passing them around has the same effect and is IMHO less opaque.
Just my 0.02€