How spring container works for Singleton scope

[Anand Surya]

Hi Experts,

I have doubt like,

Suppose I have bean UserLogin with the default scope i.e Singleton(only once instance per container(correct me if my understanding is wrong)).
And I have web application it contains the one container with one context which has my bean(UserLogin bean) with Singleton scope.
Now I have logged in WebApplication with UserBean and suppose there is another user has logged in on the same WebApplication with the same UserLogin bean.

My question is how container manages the above scenario as UserLogin bean has Singleton scope and multiple users can login at a same time with the same bean instance.

Appreciate your help..!

[Anand Surya]

Is it related to Singleton scope is Stateless. If yes then please explain how?

[Stephan van Hulst]

Welcome to CodeRanch!

Spring will only create one instance of a bean with the Singleton scope for the lifetime of the Spring container. That means if you inject a UserLogin for two different user sessions during the same lifetime of the application, both will have the same UserLogin instance injected.

Singleton- or application-scoped beans must be stateless. They are initialized once, and their state should not change afterwards. The reason is that these beans are shared between different, possibly concurrent requests. If you make them stateful, you need to synchronize between requests, which causes a huge performance hit.

Request- and prototype-scoped beans can be stateful, since they are only ever handled by one thread. At least... you're not spawning new threads from your requests, are you?

Session-scoped beans are tricky. They're typically stateful because you use them to keep track of information between separate requests, but because they can be accessed by multiple requests concurrently, you have to make them thread-safe. Since you only synchronize between requests belonging to the same session, the performance overhead is not a big issue.

[Anand Surya]

Thanks a lot Stephan.
I have one more doubts like, you said

"That means if you inject a UserLogin for two different user sessions during the same lifetime of the application, both will have the same UserLogin instance injected."

Who creates different sessions and injects the UserLogin is the Spring container creates or else and how?

Thanks once again.

[Stephan van Hulst]

When you run a WAR inside a servlet container, the container will create a ServletContext that will remain in memory for as long as your application is loaded. Then, for each Spring servlet in your application, Spring will create an ApplicationContext. When a user makes a request, the servlet container creates a HttpServletRequest, and if the request doesn't have a session cookie or if the session cookie has expired, the servlet container will also create a HttpSession.

Now, Spring will associate beans with one of these objects, depending on which scope you've declared.

application: Associated with the ServletContext, so you only have the same bean per web application.

singleton: Associated with the ApplicationContext, so you only have the same bean per Spring servlet.

session: Associated with the HttpSession, so you have one bean per session.

request: Associated with the HttpServletRequest, so you have one bean per request.

prototype: Not associated with anything. Spring injects a new bean every time.

[Tim Holloway]

I have a bigger doubt. DON'T WRITE YOUR OWN SECURITY. Unless you are a full-time professionally-trained security professional, it's about 95% certain that someone can crack your security system. And, based on what I've seen over the years, about an 85% chance that non-technical people will be able to bypass security in 15 minutes or less. That includes systems designed by the in-house "genius".

J2EE/JEE defines a standard container-based security subsystem. In nearly 20 years, I've never heard of it being breached. It's pre-written, pre-debugged, tested by security pros, well-documented, and best of all, it blocks most security attacks before they can attack the web application itself. Consider using it.

Spring also provides a finer-grained security system itself, which I believe actually can work in concert with container security.

So there's no excuse for writing your own security management in most cases.

[Peter Rooke]

The amount of times I've started on a new project and been told "We wrote our own!"  And I'm thinking "F*** NO, not again!".   Not Invented Here Antipattern

This may help; Spring Security Example

 

[Anand Surya]

Tim Holloway wrote:I have a bigger doubt. DON'T WRITE YOUR OWN SECURITY. Unless you are a full-time professionally-trained security professional, it's about 95% certain that someone can crack your security system. And, based on what I've seen over the years, about an 85% chance that non-technical people will be able to bypass security in 15 minutes or less. That includes systems designed by the in-house "genius".

J2EE/JEE defines a standard container-based security subsystem. In nearly 20 years, I've never heard of it being breached. It's pre-written, pre-debugged, tested by security pros, well-documented, and best of all, it blocks most security attacks before they can attack the web application itself. Consider using it.

Spring also provides a finer-grained security system itself, which I believe actually can work in concert with container security.

So there's no excuse for writing your own security management in most cases.

But still I did not understood, how actually one Spring singleton scope(e.g. LoginUser) bean works for multiple users on the same context or container?

[Tim Holloway]

If you use J2EE standard login, there is no Spring bean, whether singleton or not. J2EE container login is done entirely by the webserver. No application code is executed, therefore no Spring is used.