I had been reading up on Spring framework documentation and came across this line.
As a rule, use the prototype scope for all stateful beans and the singleton scope for stateless beans.
Couldn't quiet digest it. Isn't the line above counter intuitive and just wrong?
I could accept Stateful EJBs as Prototypal beans which makes sense but wouldn't it run against the very grain or idea of a Stateless EJB to declare it as a singleton bean?
Spring bean scope and EJB -- Read Section 5.5.2 - The Prototype Scope
Related
Could someone give an overview or a summary of what the purpose of beans in a Spring framework context?
I understand the standard Java bean (no arg constructor, getters/setters, often serialized), but the Spring bean purpose seems to be different.
Is it a way of implementing the Singleton design pattern (one instance, for like factory classes) in a simple, reusable fashion?
I've mainly used Spring with annotations, but I feel I need to grasp this in order to understand Spring.
Thanks!
Beans are objects that form the backbone of the application.
A bean is simply an object that is instantiated, assembled and otherwise managed by a Spring IoC container; other than that, there is nothing special about a bean.It is in all other respects one of probably many objects in your application.
Spring beans are defined in a spring configuration file or by using annotations, instantiated by the Spring container, and then injected into your application.
Spring beans will not be singleton design pattern until you explicitly make them to be.The singleton design pattern and the spring scope 'singleton' are different things.You can define different bean scopes depending on your requirements.
The scopes could be :
singleton – Return a single bean instance per Spring IoC container
prototype – Return a new bean instance each time when requested
request – Return a single bean instance per HTTP request.
session – Return a single bean instance per HTTP session.
globalSession – Return a single bean instance per global HTTP
session.
The default scope is singleton.
I understand the standard Java bean (no arg constructor,
getters/setters, often serialized), but the Spring bean purpose seems
to be different.
You mean always serialized. Why do you think the purpose seems different?
In the end, you write classes. A lot of time these are POJOs, Plain Old Java Objects. Sometimes you implement an interface or extend a class, but its all just classes.
Beans are just classes. Don't overcomplicate it.
Now Spring might take your beans (classes) and manage them for you via any of a number of policies (prototype, singleton) but that doesn't change what a bean is, it speaks to how Spring manages the bean.
To understand best, you should get familiar with dependency injection. In a few words dependency injection allows you to use objects, or services without explicitly creating them (of course, it gives other benefits, but let's focus on the question). This is achieved by maintaining a dependency container that is - roughly said - a collection of beans.
A bean is a service/component you use in your application. Unlike the EJB, with Spring the bean is not constrained to constructor arguments or specific annotations (especially if you use xml contexts). You register a bean with a container (by defining a context), and when you require it, the container will provide you with an instance of that bean. In order to create the bean, the container examines its class and constructors, and uses any other registered beans within that context, to call the appropriate constructor or property setter.
You can configure a bean to be a singleton - this is not a singleton as in the design pattern term. Singleton beans are created once within the container, and the same instance is used whenever the bean is requested from that container. You can also use the prototype scope to force the container to create a new instance each time.
In EJB because of performance reasons beans should be stateless, then application server can maintain pool of beans and assign them to requesting clients.
What is Spring equivalent for such type of beans? In Spring we've got other scopes of beans: singleton, prototype, request, session, global session.
Each Spring bean should be implemented statelessly as a singleton. Do not introduce state into a singleton bean. There is no real benefit from pooling in such an architecture.
Spring beans have 2 types of scopes (if you do not take into account scopes for web): singleton, which is default and prototype. Roughly they implement singleton and prototype design patterns within context.
So if the bean has prototype scope it can hold a unique state like the stateful bean in EJB. When the scope of the bean is singleton the container will create only one instance of it. So we can say that singleton beans in EJB 3.1 is the analogue of singleton beans in spring.
But how I can get the features of stateless beans in Spring (I'm referring to pooling of stateless beans in EJB containers and about that each thread has a unique instance of the stateless bean)?
Either you can make the bean thread-safe, and a singleton bean is OK (that's the majority of the cases).
Or you can't, and you'll have to use a prototype. The difference I see between Spring prototype beans and stateless EJB session beans is that stateless session beans are pooled. But in these ages, pooling them or creating a new instance each time won't make much difference. Creating a new instance each time might even help the GC.
I am reading spring through its official documentation and at one place I came to a line that uses prototype scope for all stateful beans while singleton for stateless beans.
I know there is something as stateful as well as stateless beans in EJB but this is not what they have mentioned in the documents.
Can anyone explain to me what exactly this means of stateful as well stateless beans in Spring
Thanks in advance
From spring perspective
stateless beans: beans that are singleton and are initialized only once. The only state they have is a shared state. These beans are created while the ApplicationContext is being initialized. The SAME bean instance will be returned/injected during the lifetime of this ApplicationContext.
stateful beans: beans that can carry state (instance variables). These are created EVERY time an object is required (like using the "new" operator in java).
These are not EJB statfull/stateless session beans.
There is no point in storing specific information like client data, per request data in Singleton bean as they are created only once by Spring IOC container. That's why singleton beans are stateless. They are shared resources. They can only be used for storing global information.
When a request is made for creating a prototype bean, a new request is created every time. So, they can be used to store some specific information for each request. So they are stateful.
It totally depends on the implementation. See tomee for example http://tomee.apache.org/statelesscontainer-config.html . You'll have to check in your server docs
I have a service in my application which is a singleton.
My application is being bloated with the use of spring framework.
I am confused over to use the singleton service as
1: Plain Old Singleton [Access them statically when required]
OR as a
2: Spring singleton bean. [Use DI to inject when required]
Which approach is correct ?
The Spring singleton scope is not the same as the Singleton design pattern, which is not the same as a class with static methods.
From the documentation
"Please be aware that Spring's concept of a singleton bean is quite different from the Singleton pattern as defined in the seminal Gang of Four (GoF) patterns book. The GoF Singleton hardcodes the scope of an object such that one and only one instance of a particular class will ever be created per ClassLoader. The scope of the Spring singleton is best described as per container and per bean. This means that if you define one bean for a particular class in a single Spring container, then the Spring container will create one and only one instance of the class defined by that bean definition."
Also, note you need to be very careful using a Spring singleton as a service that web requests will utilize. Since each request is on its own thread, you can have threading issues if your singleton maintains any state.
To answer your question: Create a class that implements an interface, and use Spring to DI it appropriately. If your service does not maintain state, you can scope it to singleton, otherwise you can scope it to prototype.
I use Spring's beans whenever possible. The framework was designed to manage these things, and it is probably better than me at it. Another reason to use Spring's dependency injection is the possibility to unit-test with mocks instead of the real utility code, thus focusing the unit-test to the exact scope.
EDIT:
To answer the question in the comment, the only case I can think of for a non-bean singleton would be a utility code class, which would contain short pieces of generally reusable code in public static methods. Anything else requires instantiation, and therefore - a bean.