Is it to ensure that the controllers are thread safe?
If the above case is true, then is it necessary to go through the overhead of bean creation for each request rather than making the controller code not rely on instance variables?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Is it to ensure that the controllers are thread safe?
If the above case is true, then is it necessary to go through the overhead of bean creation for each request rather than making the controller code not rely on instance variables?
Your default position should be to use singleton controllers which are thread-safe. This partly for performance reasons, as you say, and partly for reasons of good design – a large mass of stateful, request-scoped beans is a mess.
Using request-scoped controllers (or other request-scoped beans) is a specialised requirement which you should only use when you have good reason to do so, i.e. you have beans whose state must be private to the lifecycle of that particular request.