Reputation: 702
It is generally said that choose only those beans as singleton that don’t have state. I am new to Spring and reading about bean scope in Spring.
My first query was what this STATE actually mean with respect to Bean?
Secondly, Why it is recommended to use singleton scope with only stateless bean? Is there some thread safe related limitations or Is there any other reason?
Upvotes: 3
Views: 3336
Reputation: 18762
Any member attributes of class is referred to as its state.
Classes with no mutable state are best suitable for becoming a Spring (singleton) beans. Mutable state refers to those member attributes to which new values can be assigned after the object has been constructed.
Beans like DAOs which have member attributes such as JpaRespository can be considered to have fairly immutable state, as no one assigns new values to JpaRespository attribute once DAO object has been initialized.
Only beans which have no state (no member attributes) or have immutable state (member variables whose values are not updated once they have been assigned a value) are the ideal candidates for becoming Spring bean. This is because most Spring beans are configured as Singleton beans, and are used by multiple threads in the container. Imagine if you had mutable state and multiple threads were trying to update state of singleton bean, you will never have predictable result.
If your bean is not Singleton, but instead it is a Prototype bean, then, that bean can have state as such beans are created and destroyed as per need.
Upvotes: 4
Reputation: 7641
In which state of object you want to run your program.When you design and write your class you do not know whether client use it as singleton OR prototype. The container configures object .So,it might be singleton OR prototype .For example TransactionAwareDataSourceProxy class of spring framework is written to run in either protoype Or singleton.The class is written in such a way that it is safe from multithrading access .As the state that is shared by all threads is made common via DI container with some setter method.So,the configuration as singleton is made at startup via container and its common value is used by all threads Or single thread.The setting of instance variable is made only once with some setter method. For example in class TransactionAwareDataSourceProxy there is reobtainTransactionalConnections as instance variable.
public TransactionAwareDataSourceProxy()
{
reobtainTransactionalConnections = false;
}
public TransactionAwareDataSourceProxy(DataSource targetDataSource)
{
super(targetDataSource);
reobtainTransactionalConnections = false;
}
public void setReobtainTransactionalConnections(boolean reobtainTransactionalConnections)
{
this.reobtainTransactionalConnections = reobtainTransactionalConnections;
}
These are the places in code where reobtainTransactionalConnections is iniatialized .If you decided to make this class singleton via DI container you set in once either with constructor injection OR setter injection.So,if we make setter injection then setReobtainTransactionalConnections will be either true Or false and remains same throughout the object life time.I think thats the advantages of configuring object with container ,the object state control can be easily made
Upvotes: 0
Reputation: 9954
An object (and a bean is an object) has a state if the calls to methods do not only depend on the parameter given to the method call but also to the previous calls.
In principle if you have any instance variables you have likely a state. The only exception to this is that singletons stored in instance (not static
) variables (which is quite usual in spring programming) don't count to the state.
When using a multithreaded environment a state in a singleton can have side effects. E.g. one thread sets the state (e.g. a connection to open) and another thread does not expect this state. Then one thread could fail.
Upvotes: 0