Spring Singleton, Request, Session Beans and Thread Safety

Tarun SapraNovember 2nd, 2011Last Updated: October 21st, 2012

1 317 2 minutes read

The Spring framework ecosystem comprising of so many useful frameworks has become the backbone of many Java EE application. But at the core of all the spring products we still have the Spring DI/IOC framework which has catapulted Spring to all new heights.

As more people are adopting Spring MVC or a JSF-Spring integration for their application, the Spring beans are now more frequently used with request/session scope apart from their more traditional counterparts of Singleton and Prototype scopes.

One of the initial curiosities of a developer just starting out with various Spring scopes is that how do these scope behave in a web application and in situations which require writing safe concurrency code. Well the answer to this no to over-think about these scope as they behave exactly the way they have been named. Let’s take a example of JSF- Spring integration wherein all the JSF beans are loaded by the Spring IOC container and Scope of the beans are also defined using suppose Spring’s @Scope annotation.

The bean with @Scope(“request”) would be created for anywhere new incoming request thus it’s thread safely is guaranteed since it’s created everytime a new request comes in. Next is the @Scope(“session”) bean which would be same for every session of the user, in case of user accessing the application through multiple tabs of the browser this bean scope can surely give concurrency issues thus it’s important for the developer to make sure that the state of the shared session data doesn’t become corrupt.

Now comes the @Scope(“singleton”) or the default scope of the Spring beans, how do these singleton beans behave in a heavy load web application. Well first of all it’s important to understand that “Singleton” means only one instance i.e. the application will have only one instance of that bean. Now Spring framework doesn’t do anything under the hood concerning the multithreaded behavior this Singleton bean i.e. it’s just a normal Singleton bean and it’s upto the developer to handle the Concurrency issues pertaining to this bean.

Now the question arises what kind of beans should be Singleton in a web application, well the answer is pretty straightforward: Any Bean without STATE can be a singleton. For example beans that easily qualify to be singleton are DAO, Service, Controller these beans don’t have their own states instead we leverage these beans in our application to perform certain operations.. The DAO layer beans can be singleton as they don’t have their own state but every thread accessing them using the DAO bean to perform certain thread specific operation thus the DAO bean remains unaffected by it’s own concurrent access because it doesn’t have it’s own state.

A really bad example of choosing a Singleton bean would be a bean that needs to maintain it’s state in that case each thread would try to impose it’s own state on that bean there by corrupting the data. For example if a Person bean with setters and getter for name and age is made singleton. Now if multiple threads start accessing this bean they would keep overriding the last set values of the Person’s instance thereby corrupting the state.

Conclusion – Remember the golden rule: Choose only those beans as singleton that don’t have state

Reference: Spring Singleton, Request, Session Beans and Thread Safety from our JCG partner Tarun Sapra at the “Java Enterprise Ecosystem” blog.

Related Articles :