Dec 15th, 2004, 05:02 PM
Issues with multithreading and controllers?
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!
Dec 16th, 2004, 03:58 AM
Re: Issues with multithreading and controllers?
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.
Originally Posted by brianstclair
Read up about the Servlet threading model. The same applies to stuff running inside the servlet.
Dec 16th, 2004, 09:18 AM
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.
Dec 16th, 2004, 08:50 PM
I guess the key to understanding this is that every thread has its own stack.
Dec 22nd, 2004, 07:05 AM
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.
Originally Posted by brianstclair
Dec 22nd, 2004, 09:12 AM
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.
Dec 23rd, 2004, 09:24 AM
Thanks to all who replied - greatly appreciated!
Feb 10th, 2010, 07:47 AM
multithreading in struts,tiles and spring
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?
Feb 10th, 2010, 08:17 AM
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.
Feb 10th, 2010, 08:24 AM
@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€